from:"O. Hartmann"

Am Fri, 31 Oct 2014 16:46:15 + (UTC)
John Dison jdiso...@yahoo.com schrieb:

 Hello!
 I want to use NVidia Tesla K40 GPU for parallel computing.Does FreeBSD 
 support such a
 hardware? Thanks a lot!
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


You're out of luck. No, FreeBSD doesn't support GPGPU computing on modern 
graphics
hardware. Since 2009 we try to utilize FreeBSD for such a purpose, especially 
with
the use of OpenCL for high performance computing.

Around 2010 there was the glimpse of a dawn with Pathscale, offering a 
OpenACC-precursor
with their compiler infrastructure, supposed to be capable of utilizing FreeBSD 
and
nVidia GPUs (that time Tesla) with Pathscale-libraries (I forgot the name, it's 
CAPS or
something like that) but at the end it revealed its self as a heap of 
unfinished,
unmature code and by now the company or ist successor doen't even provide a 
commercial
product for FreeBSD - the project died!

It is even worse: FreeBSD ports dropped Nouveau! There are effords bringing 
libclc, the
new Mesa library, Glover and OpenCL in combination with LLVM 3.4/3.5 together 
to provide
OpenCL and via LLVM the nVidia PTX backend, but as far as I know this work is 
still under
development and immature and FreeBSD is no longer part of the scene due to the 
drop of
the Nouveau driver (I was told FreeBSD lacks important kernel features known 
for years
for KMS).

CUDA is completely out of view: nVidia doesn't provide support for FreeBSD. 
nVidia
fellows claim there is no need/request from FreeBSD people. I believe it is 
simply
ignorance and a stupid political issue, made years ago, that we suffer from by 
now.

The situation with open source AMD driver (radeonSI) is unknown to me. We made 
very bad
experiences with AMD hardware in the era of the AMD HD46XX/47XX and HD48XX 
chipsets and
the development is/was behind the recent chips available on market. On Linux 
there were
reports of successfully running OpenCL kernels on the radeonSI drivers with 
Glover/Mesa
and other mandatory software not available for FreeBSD - the FreeBSD X11 base 
system is
also methusalem and behind the recent development. If you would go with AMD, 
you would
have to stay with open source since AMD doens't provide BLOBs for their GPUs 
for FreeBSD.
For Linux, the AMD OpenCL SDK is very nice, their hardware is pretty fast ( 
nVidia!)
while their driver tend to crash. But as said, Linux only.

With nVidia you get a pretty fast and nice BLOB for all FreeBSDs and modern 
GPUs from
nVidia, but there is no OpenCL backend lib (or CUDA). Either way, it is a dead 
end with
FreeBSD.

There was also once a setup with the FreeBSD Linuxulator - but this is 32bit 
only and a
no go for serious scientific compuations. We also tried this with more modern 
FreeBSDs
(8.X, 9.X, 10-CURRENT that time), but with CUDA  4 you're out of luck. And 
FreeBSD
doesn't have a 64bit support in the Linuxulator. And why running a Linuxulator?

If you really plan to use a beast like K40, consider dropping FreeBSD and using 
Linux! We
started with Ubuntu and OpenSuse that time. At the first moment the shock is 
heavy, but
you'll come along with Linux very soon. The only bad thing is the missing ZFS 
support as
someone might be used to in FreeBSD but this is also only a question of time 
(more short
than long!). Linux development is pretty fast these days, support is excellent 
and Linux
suffers from bad karma from the days of the Linux 2.4 kernel. That has changed
dramatically. A department developing security facilities is now dropping 
OpenBSD in
favour of Debian Linux, even OpenBSD is still considered more bullet proof. 
But the
decision was made due to a dramatic driver issue - I mention this here because 
also
FreeBSD seems to suffer increasingly (compared to to Linux) from driver issues 
for high
performance equipment (special interlink adaptors, WiFi NICs and even the GPU 
issue!).

I'm very sad having no better experience to tell.

oh 


pgpiAVMAsCSDT.pgp
Description: OpenPGP digital signature

CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!


On all CURRENT systems I updated today (31.10.2014) I had massive filesystem 
corruption
after reboot. The systems do have 

FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64

and suffer without exception from the same breakage, quitting services and/or 
reporting
corrupted filesystems after a fresh reboot - even if I've performed a manual 
triggered
fsck -fz in single user mode on the console.

All systems have GPT partion schemes.

The problem is serious! I can not get rid via fsck of the problem of corrupted
filesystems. Services like OpenLDAP (Slapd), nslcd, dbus, hal or postgresql do 
not start
properly and need to be started manually after a reboot.

What is wrong? The fact that several CURRENT boxes are affected the very same 
way ( 5 )
make me confident this is a serious bug recently introduced.

Oliver


pgpq78x9cSl2E.pgp
Description: OpenPGP digital signature

Re: Unclean shutdown for r273852 - r273899 transition

Am Fri, 31 Oct 2014 06:59:12 -0700
David Wolfskill da...@catwhisker.org schrieb:

 I thought it a bit odd when I rebooted after the make installworld
 completed and found that fsck(8) was checking teh file systems on my
 laptop.
 
 When it also happened for my build machine, I suspected it might not
 merely be a one-off oddity... and I was able to make use of the serial
 console on the build machine.
 
 THe laptop started out running:
 
 FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1412
 r273852M/273852:1100040: Thu Oct 30 05:25:51 PDT 2014
 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386
 
 this morning; I performed an in-place source upgrade to:
 
 FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1413
 r273899M/273900:1100041: Fri Oct 31 06:01:13 PDT 2014
 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386
 
 
 Here's what things looked like on the cosnole for the build machine (which
 had been built from sources at the same revisions):
 
 Oct 31 06:40:09 freebeast shutdown: reboot by david: 
 Stopping cron.
 Waiting for PIDS: 723.
 Stopping sshd.
 Waiting for PIDS: 713.
 Stopping rsyncd.
 Waiting for PIDS: 686.
 Stopping powerd.
 Waiting for PIDS: 671.
 Stopping ntpd.
 Waiting for PIDS: 668.
 Stopping lpd.
 Waiting for PIDS: 647.
 Stopping lockd.
 Waiting for PIDS: 630.
 Stopping statd.
 Waiting for PIDS: 627.
 Stopping nfsd.
 Waiting for PIDS: 623 624.
 Stopping mountd.
 Waiting for PIDS: 617.
 Stopping casperd.
 Waiting for PIDS: 595.
 Stopping amd.
 Waiting for PIDS: 587.
 Stopping ypbind.
 Waiting for PIDS: 582.
 Stopping rpcbind.
 Waiting for PIDS: 491.
 Stopping devd.
 Waiting for PIDS: 407.
 Writing entropy file:.
 .
 TermiOct 31 06:40:14 freebeast syslogd: exiting on signal 15
 Waiting (max 60 seconds) for system process `vnlru' to stop...done
 Waiting (max 60 seconds) for system process `syncer' to stop...
 Syncing disks, vnodes remaining...5 6 6 6 6 4 4 4 4 4 3 1 1 1 1 1 1 1 1 0 0 0 
 0 0 0 done
 Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
 All buffers synced.
 lock order reversal:
  1st 0xc7925388 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1223
  2nd 0xc7a7a7f8 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375
 KDB: stack backtrace:
 db_trace_self_wrapper(c11ac524,c6da28c8,c156af90,c156afa4,e1fb9890,...) at
 db_trace_self_wrapper+0x2d/frame 0xe1fb9828
 kdb_backtrace(c11b00a9,c7a7a7f8,c11a2e94,c6daa3e0,c11e2149,...) at
 kdb_backtrace+0x30/frame 0xe1fb9890 
 witness_checkorder(c7a7a7f8,9,c11e2149,55f,0,...)
 at witness_checkorder+0xd0c/frame 0xe1fb98e0
 __lockmgr_args(c7a7a7f8,80400,c7a7a818,0,0,0,c11e2149,55f) at
 __lockmgr_args+0x8f3/frame 0xe1fb99bc
 vop_stdlock(e1fb9a30,c11e2149,63d,1244,c7a7a838,...) at vop_stdlock+0x4d/frame
 0xe1fb99ec VOP_LOCK1_APV(c140ddac,e1fb9a30,0,0,c145ac60,...) at
 VOP_LOCK1_APV+0x10a/frame 0  __      _ _ |
 | |  _ \ / |  __ \ | |___ _ __ ___  ___ | |_) | (___ | |  
 | | |
 ___| '__/ _ \/ _ \|  _  \___ \| |  | | | |   | | |  __/  __/| |_) |) | 
 |__| | |
 |   | | |||| |  |  | |_|   |_|  
 \___|\___||/|_/|_/
 ```` s` `.---...--.```   -/ ... 
 
 (The stack bactrace is obviously truncated.)
 
 ...
 Booting...
 GDB: no debug ports present
 KDB: debugger backends: ddb
 KDB: current backend: ddb
 Copyright (c) 1992-2014 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 11.0-CURRENT #1651  r273899M/273900:1100041: Fri Oct 31 06:31:31 PDT 
 2014
 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386
 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
 WARNING: WITNESS option enabled, expect reduced performance.
 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.20-MHz 686-class CPU)
   Origin=GenuineIntel  Id=0xf41  Family=0xf  Model=0x4  Stepping=1
   
 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
   Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR
   AMD Features=0x2010NX,LM
   TSC: P-state invariant
 real memory  = 2147483648 (2048 MB)
 avail memory = 2077032448 (1980 MB)
 Event timer LAPIC quality 400
 ACPI APIC Table: PTLTD  APIC  
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 2 package(s) x 1 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  6
 random device not loaded/active; using insecure pseudo-random number generator
 ioapic0 Version 2.0 irqs 0-23 on motherboard
 ioapic1 Version 2.0 irqs 24-47 on motherboard
 ioapic2 Version 2.0 irqs 48-71 on motherboard
 random: entropy device infrastructure driver
 random: selecting highest priority adaptor Dummy
 kbd1 at kbdmux0
 random:

Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!

Am Fri, 31 Oct 2014 22:23:28 +0100
Dag-Erling Smørgrav d...@des.no schrieb:

 Can you all please tell me which revision(s) you were running before you
 upgraded?  Something like bzgrep 11.0-CURRENT /var/log/messages*
 should do the trick.
 
 DES
r273800 was the last (obviously) working on one box, r273872 seems to have the 
problem:

/var/log/messages:Oct 30 05:53:45 0.2 gate kernel: FreeBSD 11.0-CURRENT #0 
r273800: Tue
Oct 28 21:24:08 CET 2014 /var/log/messages:Oct 31 05:32:25 0.2 gate kernel: 
FreeBSD
11.0-CURRENT #1 r273872: Thu Oct 30 22:32:59 CET 2014 /var/log/messages:Oct 31 
19:59:55
0.2 gate kernel: FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014


r273746: Mon Oct 27 21:43:42 CET 2014 is the one I'm sure it worked flawless.

I did the past two days daily builds.



pgpp1KfU39tUM.pgp
Description: OpenPGP digital signature

Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so

2014-10-30 Thread O. Hartmann

On CURRENT (FreeBSD 11.0-CURRENT #0 r273810: Wed Oct 29 07:52:22 CET
2014 amd64) a running net/openldap24-sasl-server system is installed and
running and is now about to be the database backend for
Kerberos/Heimdal. net/openldap24-sasl-server is at
openldap-sasl-server-2.4.40.

The database storage scheme of the LDAP backend is MDB, as it is highly
recommended by the vendors of OpenLDAP.

Searching for suitable manuals, I found some HowTos describing how to
setup MIT Kerberos V with an OpenLDAP backend and I started following
the instructions there. Despite the fact that http://www.h5l.org/manual
is dead(!) and no usefull documentation or any kind of a hint where to
find useful documentation for Heimdal can be found, many of the MIT
Kerberos V setup instructions seem to be a dead end when using Heimdal
on FreeBSD. Most of the links on that heimdal site ends up in ERROR 404!

Well, I think my objective isn't that exotic in an more advanced server
environment and I think since FreeBSD is supposed to be used in
advanced server environments this task should be well known - but
little information/documentation is available.

Nevertheless, I use the base system's heimdal implementation and I run
into a very frustrating error when trying to run kamdin -l:

kadmin: error trying to load dynamic module /usr/lib/hdb_ldap.so:
Cannot open /usr/lib/hdb_ldap.so

The setup for the stanza [kdc] is

[...]
[kdc]
database ={
dbname=ldap:ou=kerberos,dc=server,dc=gdr
#hdb-ldap-structural-object = inetOrgPerson
mkey_file = /var/heimdal/m-key 
acl_file = /var/heimdal/kadmind.acl
}

instructions taken from  http://www.padl.com/Research/Heimdal.html.

Well, it seems that FreeBSD ships with a crippled heimdal
implementation. Where is /usr/lib/hdb_ldap.so?

I'm toying around this issue for several days now and it gets more and
more frustrating, also with the perspective of having no running samba
4.1 server for the windows domain.

Can someone give me a hint where to find suitable FreeBSD docs for a
task like this? I guess since FreeBSD is considered a server OS more
than a desktop/toy OS, there must be a solution for this. FreeBSD ships
with heimdal in the base, but it seems this heimdal is broken.

P.S. Please CC me.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so

2014-10-30 Thread O. Hartmann

:20 keltezéssel, O. Hartmann írta:
  On CURRENT (FreeBSD 11.0-CURRENT #0 r273810: Wed Oct 29 07:52:22
  CET 2014 amd64) a running net/openldap24-sasl-server system is
  installed and running and is now about to be the database backend
  for Kerberos/Heimdal. net/openldap24-sasl-server is at 
  openldap-sasl-server-2.4.40.
  
  The database storage scheme of the LDAP backend is MDB, as it is
  highly recommended by the vendors of OpenLDAP.
  
  Searching for suitable manuals, I found some HowTos describing how
  to setup MIT Kerberos V with an OpenLDAP backend and I started
  following the instructions there. Despite the fact that
  http://www.h5l.org/manual is dead(!) and no usefull documentation
  or any kind of a hint where to find useful documentation for
  Heimdal can be found, many of the MIT Kerberos V setup instructions
  seem to be a dead end when using Heimdal on FreeBSD. Most of the
  links on that heimdal site ends up in ERROR 404!
  
  Well, I think my objective isn't that exotic in an more advanced
  server environment and I think since FreeBSD is supposed to be used
  in advanced server environments this task should be well known -
  but little information/documentation is available.
  
  Nevertheless, I use the base system's heimdal implementation and I
  run into a very frustrating error when trying to run kamdin -l:
  
  kadmin: error trying to load dynamic module /usr/lib/hdb_ldap.so: 
  Cannot open /usr/lib/hdb_ldap.so
  
  The setup for the stanza [kdc] is
  
  [...] [kdc] database ={ 
  dbname=ldap:ou=kerberos,dc=server,dc=gdr 
  #hdb-ldap-structural-object = inetOrgPerson mkey_file =
  /var/heimdal/m-key acl_file = /var/heimdal/kadmind.acl }
  
  instructions taken from
  http://www.padl.com/Research/Heimdal.html.
  
  Well, it seems that FreeBSD ships with a crippled heimdal 
  implementation. Where is /usr/lib/hdb_ldap.so?
  
  I'm toying around this issue for several days now and it gets more
  and more frustrating, also with the perspective of having no
  running samba 4.1 server for the windows domain.
  
  Can someone give me a hint where to find suitable FreeBSD docs for
  a task like this? I guess since FreeBSD is considered a server OS
  more than a desktop/toy OS, there must be a solution for this.
  FreeBSD ships with heimdal in the base, but it seems this heimdal
  is broken.
  
  P.S. Please CC me. ___ 
  freebsd-current@freebsd.org mailing list 
  http://lists.freebsd.org/mailman/listinfo/freebsd-current To
  unsubscribe, send any mail to
  freebsd-current-unsubscr...@freebsd.org
  
 
 - -- 
 Tisztelettel:
 Lévai László
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iF4EAREIAAYFAlRR+GEACgkQtgVHtSvpUlo8hgD/dJbCxh7dBdm1tosZ8fdmMuCf
 o6fBH3629SPMpGxxon0A/jK7hheRgcJYaIRTVUbmwKm3clbkVW4smcNCf8dPrTq5
 =vvoI
 -END PGP SIGNATURE-
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 freebsd-current-unsubscr...@freebsd.org

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

Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so

2014-10-30 Thread O. Hartmann

On Thu, 30 Oct 2014 10:02:19 +0100
Lévai László laszlo.lev.le...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 
 
 2014-10-30 09:47 keltezéssel, O. Hartmann írta:
  On Thu, 30 Oct 2014 09:35:49 +0100 Lévai László
  laszlo.lev.le...@gmail.com wrote:
  
  Hi, try this:
  
  [1] kill all kerberos process [2] to start KDC:
  /usr/local/libexec/kdc --detach [3] /usr/local/sbin/kadmin -l 
  kadmin list -l * [...]
  
  Principal: krbtgt/... Principal expires: never Password expires:
  never Last password change: never Max ticket life: unlimited Max
  renewable life: unlimited Kvno: 1 Mkvno: unknown Last successful
  login: never Last failed login: never Failed login count: 0 Last
  modified: 2014-10-28 11:44:00 UTC Modifier: unknown Attributes: 
  Keytypes: aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt),
  arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases:
  
  Principal: kadmin/changepw@... Principal expires: never Password
  expires: never Last password change: never Max ticket life: 5
  minutes Max renewable life: 5 minutes Kvno: 1 Mkvno: unknown Last
  successful login: never Last failed login: never Failed login
  count: 0 Last modified: 2014-10-28 11:44:00 UTC Modifier: unknown 
  Attributes: pwchange-service, requires-pre-auth, 
  disallow-proxiable, disallow-renewable, disallow-tgt-based, 
  disallow-postdated Keytypes: aes256-cts-hmac-sha1-96(pw-salt), 
  des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: 
  Aliases:
  
  Principal: kadmin/admin@... Principal expires: never Password
  expires: never Last password change: never Max ticket life: 1 hour 
  Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful
  login: never Last failed login: never Failed login count: 0 Last
  modified: 2014-10-28 11:44:00 UTC Modifier: unknown Attributes:
  requires-pre-auth Keytypes: aes256-cts-hmac-sha1-96(pw-salt), 
  des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: 
  Aliases:
  
  Principal: changepw/kerberos@... Principal expires: never Password
  expires: never Last password change: never Max ticket life: 1 hour 
  Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful
  login: never Last failed login: never Failed login count: 0 Last
  modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes:
  pwchange-service, disallow-tgt-based Keytypes:
  aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt),
  arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases:
  
  Principal: kadmin/hprop@... Principal expires: never Password
  expires: never Last password change: never Max ticket life: 1 hour 
  Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful
  login: never Last failed login: never Failed login count: 0 Last
  modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes:
  requires-pre-auth, disallow-tgt-based Keytypes:
  aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt),
  arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases:
  
  Principal: WELLKNOWN/ANONYMOUS@... Principal expires: never 
  Password expires: never Last password change: never Max ticket
  life: 1 hour Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last
  successful login: never Last failed login: never Failed login
  count: 0 Last modified: 2014-10-28 11:44:01 UTC Modifier: unknown 
  Attributes: requires-pre-auth Keytypes:
  aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt),
  arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases:
  
  Principal: default@... Principal expires: never Password expires:
  never Last password change: never Max ticket life: 1 day Max
  renewable life: 1 week Kvno: 1 Mkvno: unknown Last successful
  login: never Last failed login: never Failed login count: 0 Last
  modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes:
  disallow-all-tix Keytypes: aes256-cts-hmac-sha1-96(pw-salt), 
  des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: 
  Aliases: [...]
  
  Hello.
  
  This seems not to be the base system's Heimdal since you use
  /usr/local as prefix!
  
 
 The base system's Heimdal with OpenLDAP backend not worked form me. So
 I installed the security/heimdal port and OpenLDAP24 server.
 
 root@lea:~ # /usr/local/libexec/slapd -VV
 @(#) $OpenLDAP: slapd 2.4.40 (Oct 17 2014 16:17:52) $
   
 root@lea...:/usr/ports/net/openldap24-server/work/openldap-2.4.40/servers/slapd
 
 
 root@lea:~ # /usr/local/libexec/kdc --version
 kdc (Heimdal 1.5.2)
 Copyright 1995-2011 Kungliga Tekniska Högskolan
 Send bug-reports to heimdal-b...@h5l.org
 
 
 root@lea:~ # /usr/local/libexec/kdc --builtin-hdb
 builtin hdb backends: ndbm:, keytab:, ldap:, ldapi:, sqlite:
 
 oterwise the system kdc:
 root@lea:~ # /usr/libexec/kdc --builtin-hdb
 builtin hdb backends: db:, mit-db:, ndbm:, keytab:, sqlite:
 
 
  What is your database/storage backend for your Heimdal
  installation? Is  it OpenLDAP?
  
  Tnak you very much in advance,
  
  Oliver
  
  
  
  2014-10-30 09:20 keltezéssel, O. Hartmann írta:
  On CURRENT (FreeBSD

emulators/virtualbox-ose: compilation on CURRENT fails due to: tstVMStructRC: 1: Syntax error: ( unexpected

2014-10-27 Thread O. Hartmann

Compiling emulators/virtualbox-ose on a freshly installed CURRENT
(FreeBSD 11.0-CURRENT #0 r273719: Mon Oct 27 07:59:12 CET 2014 amd64)
results in the below shown error.

I also tried to install the package on CURRENT via pkg install, but
this results in a 32-Bit VirtualBox only - which is inacceptable.

I have running emulators/virtualbox-ose on several other CURRENT
machines, but most of those boxes are grown, that means, they got
CURRENT months ago and are maintained as usual (buildworld/portmaster).
This box has been installed a couple of weeks ago and is successfully
rejecting compilation of port emulators/virtualbox-ose, although I
already updated the ports tree and did successfully a portmaster -R
-fd /emulators/virtualbox-ose.

Since I use some non-standard optimization flags in /etc/src.conf
and /etc/make.conf (-O3 and CPUTYPE=native instead of plain -O and
outdated architectural compatibilities), I switched back to the FreeBSD
vanilla standard - but still the same. I can not imagine that the CPU
of that specific box could be the culprit:


dmesg output:

CPU: Intel(R) Core(TM)
i5-3470 CPU @ 3.20GHz (3192.82-MHz K8-class CPU) Origin=GenuineIntel
Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0x7fbae3ffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND
AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF
  Structured Extended Features=0x281FSGSBASE,SMEP,ERMS
  XSAVE Features=0x1XSAVEOPT
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 9107931136 (8686 MB)
avail memory = 8147902464 (7770 MB)

I have also problems compiling the port on a newly setup laptop (Intel
i5-4200M CPU/Haswell), CURRENT as of the same date as reported here.
The failure is the same. It seems, that on CURRENT installations as of
a certain date not far in the past, the port fails to recompile
successfully. 

The error is:


[...]

kBuild: Generating tstVMStructSize
- 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h
 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/bin/tstVMStructRC:
1: Syntax error: ( unexpected kmk: ***
[/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h]
Error 2 kmk: *** Deleting file
`/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h'
kmk: *** Waiting for unfinished jobs filesplitter: Out of 144
files: 144 rewritten, 0 unchanged.
(/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include)
kmk_builtin_append
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include/COMWrappers
kmk: *** Exiting with status 2 *** Error code 2
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: WiFi 802.11/ac PCIe supported adaptor

2014-10-19 Thread O. Hartmann

Am Sun, 28 Sep 2014 14:50:02 -0600 (MDT)
Warren Block wbl...@wonkity.com schrieb:

 On Sun, 28 Sep 2014, Gavin Atkinson wrote:
  On Sun, 28 Sep 2014, O. Hartmann wrote:
  Networking wasn't an issue for me for years, but now, sitting on a pile of 
  neat new
  hardware of which FreeBSD can not make any serious use, let me rethink. 
  Luckily, The
  Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow 
  FreeBSDs agony
  I'm able to swap the NIC with a piece of hardware that is supported. But 
  it is
  additional
 
  Unfortunately, many Lenovo laptops lock the BIOS down in such a way that
  they won't boot without the NIC they were shipped with :(

Yes, I realized this very sadly today. Intel 6300 WiFi adapter isn't 
recognized, the crap
of Laptop rejects starting firmware and I get a message telling me using 
uncertified
hardware. Last time I bought a Laptop from Lenovo!

 
 Well, or a short list of approved Lenovo-branded cards.  In the past, 
 Lenovo (or IBM) has supplied Atheros cards.  The trick will be finding 
 that list and identifying the chipsets on each.  There are also 
 unofficial BIOS modifications to remove the limits.

There are lists, but they are outdated and newer chipsets aren't listed. 

There are also some bad hacks changing the PCI ID of the new mini PCIe card to 
be
recognized by the EFI, but this seems to be very, very difficult to me.

The notebook is now running Ubuntu 14.04. WiFi is recognized by the Linux 
natively as
well as I can use the nVidia graphics of the notebook. Also the built-in 
Realtek NIC,
which doesn't work properly even under FreeBSD 11.0-CURRENT as of Friday last 
week (the
NIC is down until it is switched off and on manually), is working as expected.


signature.asc
Description: PGP signature

projects/ipfw: Consider using tcp/31982 in firewall_myservices.

2014-10-19 Thread O. Hartmann


Having simply a number (the port) in rc.conf: firewall_myservices defined, I 
receive
during startup the message

Consider using tcp/31982 in firewall_myservices.

Doing so, ends up in a misconfiguration, because the rc.firewall script in 
/etc/ is
looking for 31982/tcp instead of the recommended tcp/31982.

This is a typo.

oh


signature.asc
Description: PGP signature

Re: i915 driver update testing

2014-10-08 Thread O. Hartmann

Am Sun, 05 Oct 2014 21:54:22 +0200
Koop Mast k...@rainbow-runner.nl schrieb:

 On Fri, 2014-10-03 at 20:02 +0300, Konstantin Belousov wrote:
  Please find at the
  https://kib.kiev.ua/kib/drm/i915.1.patch
  a patch which provides some updates to the i915 driver. At large, this
  is import of the batch of Linux commits, and as such, it is interesting
  mostly as attempt to restart the race to get us more up to date Linux code
  imported. It might provide some bug fixes, most likely for IvyBridge.
  Interesting from the development PoV is the update of the GEM i/o ioctl
  code path to mimic Linux code structure.
  
  I am asking _only_ for reports of regressions with the patch applied,
  comparing with the code which is currently in HEAD. I will not debug
  any existing bugs, my goal right now is to commit this update, which is
  needed for further work. I.e., only when you get an issue with the patch
  applied, but cannot reproduce the problem without the patch, please
  prepare a bug report.
  
  FYI, the driver will attach to haswell gfx, but I am not interested in
  reports about this (see above paragraph). On my test box, which is Core
  i7 4770S, the mode-setting and front-buffer rendering works, but Mesa
  immediately cause renderer to bug out.
  
  Work was sponsored by The FreeBSD Foundation, both by time and hardware,
  and Intel provided access to the documentation.
 
 Hi, I got a working X-server and framebuffer console on my Sandybridge
 system. The only regression I noticed so far is the line below, where
 the number after 'expected' changes per time the line is printed. 
 
 Oct  5 21:50:12 crashalot kernel: error: [drm:pid1049:gen6_sanitize_pm]
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected
 160d, was 1600
 Oct  5 21:51:04 crashalot kernel: error: [drm:pid1049:gen6_sanitize_pm]
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected
 160d, was 1600
 Oct  5 21:53:14 crashalot kernel: error: [drm:pid1170:gen6_sanitize_pm]
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected
 160d, was 1600
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Is this patch supposed to work also with IvyBridge type iGPUs, i.w. P4600 (the 
iGPU of
some XEONs of the i5-122Xv2 series)?

When I load drm2 and i915kms via loader.conf, the box gets black screen and 
then dies.

Oliver 


signature.asc
Description: PGP signature

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

2014-10-06 Thread O. Hartmann

Am Sun, 5 Oct 2014 15:20:20 -0700
Mark Johnston ma...@freebsd.org schrieb:

 On Sun, Oct 05, 2014 at 11:18:55AM +0200, O. Hartmann wrote:
  Am Sun, 5 Oct 2014 05:36:57 +0400
  Arseny Nasokin eir...@gmail.com schrieb:
  
   Mark,
   
   Thank you for patch, I encounter same error and this patch works for me.
   
   ✪
   
   
   -- Eir Nym
   
   On 5 October 2014 04:43, Mark Johnston ma...@freebsd.org wrote:
   
On Sat, Oct 04, 2014 at 04:41:07PM -0700, Russell L. Carter wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



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

 Even poudriere can't get past this one.
   
Sorry, it was incomplete. It's been updated:
http://people.freebsd.org/~markj/patches/libctf_prebuild.diff
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
freebsd-current-unsubscr...@freebsd.org
   
   ___
   freebsd-current@freebsd.org mailing list
   http://lists.freebsd.org/mailman/listinfo/freebsd-current
   To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
  
  After some minor corrections to the patch (the patched original sources 
  seem not to
  match most recent CURRENT sources as of revision 272562), buildworld works 
  again as
  expected.
  
  Thank you very much.
 
 Committed as r272576. Sorry for the breakage.
 
 The patch was generated from my git tree, which didn't contain r272484,
 so the patch wouldn't apply to svn cleanly. I'll be sure to check that
 next time. :(
 
 Thanks,
 -Mark
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

... everything is shiny here ...

Oliver


signature.asc
Description: PGP signature

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

2014-10-05 Thread O. Hartmann

Am Sat, 4 Oct 2014 15:58:48 -0700
Mark Johnston ma...@freebsd.org schrieb:

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

This patch doesn't apply with sources at rev. 272559, as it bails out. 
Investigating the
situation shows, that my top-level Makefile.inc seems different from what the 
patch is
supposed to expect:

root@gate [src] patch -p1  /tmp/libctf_prebuild.diff
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/Makefile.inc1 b/Makefile.inc1
|index 3b92aef..9350339 100644
|--- a/Makefile.inc1
|+++ b/Makefile.inc1
--
Patching file Makefile.inc1 using Plan A...
Hunk #1 succeeded at 1536 with fuzz 1 (offset 2 lines).
Hunk #2 failed at 1584.
1 out of 2 hunks failed--saving rejects to Makefile.inc1.rej
done



The patch at line 1530 ff:

[...]
lib/libgeom \
${_cddl_lib_libumem} ${_cddl_lib_libnvpair} \
${_cddl_lib_libuutil} \
${_cddl_lib_libavl} \
${_cddl_lib_libzfs_core} \
${_cddl_lib_libctf} \
lib/libutil lib/libpjdlog ${_lib_libypclnt} lib/libz lib/msun \
${_secure_lib_libcrypto} ${_lib_libldns} \
${_secure_lib_libssh} ${_secure_lib_libssl}

My source tree is clean and sober as svn status reports.

A bit spooky, isn't it?

Oliver


signature.asc
Description: PGP signature

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

2014-10-05 Thread O. Hartmann

Am Sun, 5 Oct 2014 05:36:57 +0400
Arseny Nasokin eir...@gmail.com schrieb:

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

After some minor corrections to the patch (the patched original sources seem 
not to match
most recent CURRENT sources as of revision 272562), buildworld works again as 
expected.

Thank you very much.

Oliver


signature.asc
Description: PGP signature

Re: CURRENT: EFI boot failure

2014-10-04 Thread O. Hartmann

Am Tue, 23 Sep 2014 16:51:08 +0200
Harald Schmalzbauer h.schmalzba...@omnilan.de schrieb:

  Bezüglich Harald Schmalzbauer's Nachricht vom 23.09.2014 16:28
 (localtime):
   Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
  …
  The problem I reported about in the first place is triggered by a faulty 
  loader.efi
  that arises, when optimisation level is -O3. -O2 works fine.
  I can confirm that this problem also shows up when using
  'CPUTYPE?=core-avx2'
  Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
 
  I could narrow down the cause to libefi.a (sys/boot/efi).
  But I don't understand the things going on there, so no clue how to fix
  besides maybe
 
  --- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
  +++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
  @@ -2,6 +2,10 @@
 
  BINDIR?= /boot
 
  +.ifdef CPUTYPE
  +.undef CPUTYPE
  +.endif
 
 Sorry, forget the suggestion, it doesn't work since it leads to CFLAG
 -march= and the same problem occurs.
 For my case this works:
 --- sys/boot/efi/Makefile.inc.orig  2014-09-23 16:22:46.0 +0200
 +++ sys/boot/efi/Makefile.inc   2014-09-23 16:46:30.0 +0200
 @@ -2,6 +2,10 @@
  
  BINDIR?=   /boot
  
 +.if ${CPUTYPE} == core-avx2
 +CPUTYPE=   core-avx-i
 +.endif
 +
  .if ${MACHINE_CPUARCH} == i386
  CFLAGS+=-march=i386
  .endif
 
 JFI
 
 -Harry
 

Has this problem anyhow seriously been addressed? I run into this very often on 
several
platforms with HAswell-based CPUs (other systems with IvyBridge or SandyBridge 
are still
to be migrated to UEFI boot, so I do not have any older architectures at hand 
to proof
whether this issue is still present or not on Non-AVX2 systems.

If there is no progress so far, would it be well-advised to open a PR?

Regards,
Oliver 


signature.asc
Description: PGP signature

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

2014-10-04 Thread O. Hartmann

Recent sources (Revision: 272529) fail to compile:

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

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

oh


signature.asc
Description: PGP signature

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

2014-10-04 Thread O. Hartmann

Am Sat, 4 Oct 2014 11:33:38 -0700
Mark Johnston ma...@freebsd.org schrieb:

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

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

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

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

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

Me either.

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




signature.asc
Description: PGP signature

CURRENT: ath0: stuck beacon; resetting (bmiss count 4)

2014-10-03 Thread O. Hartmann

Since a couple of days I get this weird console-and-log-spamming message:

ath0: stuck beacon; resetting (bmiss count 4)

The machine in question is running the most recent CURRENT right now:

FreeBSD 11.0-CURRENT #2 r272471: Fri Oct  3 13:03:58 CEST 2014 amd64

and the box acts as a gateway with WiFi access point via hostapd and this WiFi 
hardware:

[...]
ath0: Atheros 9287 mem 0xf7e0-0xf7e0 irq 16 at device 0.0 on pci1
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 stream STBC transmit enabled
ath0: [HT] 2 RX streams; 2 TX streams
[...]
ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0

What is this and how can I get rid of it?


Regards,
Oliver


signature.asc
Description: PGP signature

[CURRENT] hostapd: WPA w/ EAP-TTLS or EAP-PEAP or EAP-TLS ?

2014-10-03 Thread O. Hartmann


Where is the support on WPA with EAP-TTLS or EAP-PEAP or EAP-TLS  in hostapd?

Trying to circumvent FreeBSD's very poor documentation on the options of 
hostapd, I found
lots of howtos for Linuxes of different flavours utilizing obviously the same 
hostapd
basis. But whenever I try to configure one of the above mentioned auth methods 
for a
gateway I try to configure (CURRENT, 10.1-PRE), I get an error.

What is up here?

Regards,
Oliver


signature.asc
Description: PGP signature

Re: CURRENT: ath0: stuck beacon; resetting (bmiss count 4)

2014-10-03 Thread O. Hartmann

Am Fri, 03 Oct 2014 15:15:54 +0200
Erik Trulsson erik.trulsson.1...@student.uu.se schrieb:

 Quoting O. Hartmann ohart...@zedat.fu-berlin.de:
 
  Since a couple of days I get this weird console-and-log-spamming message:
 
  ath0: stuck beacon; resetting (bmiss count 4)
 
  The machine in question is running the most recent CURRENT right now:
 
  FreeBSD 11.0-CURRENT #2 r272471: Fri Oct  3 13:03:58 CEST 2014 amd64
 
  and the box acts as a gateway with WiFi access point via hostapd and  
  this WiFi hardware:
 
  [...]
  ath0: Atheros 9287 mem 0xf7e0-0xf7e0 irq 16 at device 0.0 on pci1
  ath0: [HT] enabling HT modes
  ath0: [HT] enabling short-GI in 20MHz mode
  ath0: [HT] 1 stream STBC receive enabled
  ath0: [HT] 1 stream STBC transmit enabled
  ath0: [HT] 2 RX streams; 2 TX streams
  [...]
  ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0
 
  What is this and how can I get rid of it?
 
 It means that you have run into a well-known and long lasting hardware  
 bug in Atheros Wifi chipsets, where they sometimes get stuck and stops  
 sending out beacons.
 You get that message when the device driver detects that this has  
 happened and resets the chip to get things going again.
 
 There is, AFAIK, no way of making sure the problem cannot happen, but  
 you might be able to reduce the frequency of it happening by reducing  
 the amount of interference you receive from other wireless devices.

Ah, I understand, so nothing to worry about. The WiFi NIC is a cheap TP Link 
facility.
Hopefully, FreeBSD will have support for Intel's Dual Band 7260-chipset this 
decade, so
the problem will be gone anyway (except Intel put also nice hardware bugs into 
their
silica ...).


oh


signature.asc
Description: PGP signature

pkg/ports system terribly messed up?

2014-09-30 Thread O. Hartmann


Hello.

I just made the last update of the ports yesterday (I use portmaster -da 
performing this
task) and obviously or superficially everything went all right.

I'm running on the boxes in question most recent CURRENT.

On one system, a subsequent start of updating ports starts to freak out when 
updateing
lang/gcc: it loops over and over on some ports already updated, especially
devel/binutils, but the port looping on isn't specific and varies.

On every CURRENT box I tried this morning to update the ports again, I find this
frsutrating message (depends on installation, but it seems in principal the 
same, only
the affected ports in dependency chain varies):

 === Gathering distinfo list for installed ports

=== Starting check of installed ports for available updates
=== Launching child to update openldap-sasl-client-2.4.39_2 to
openldap-sasl-client-2.4.40

=== All  openldap-sasl-client-2.4.39_2 (1/1)

=== Currently installed version: openldap-sasl-client-2.4.39_2
=== Port directory: /usr/ports/net/openldap24-sasl-client

=== Launching 'make checksum' for net/openldap24-sasl-client in background
=== Gathering dependency list for net/openldap24-sasl-client from ports
=== Launching child to install 
net/openldap24-sasl-client/../../ports-mgmt/pkg

=== All  openldap-sasl-client-2.4.39_2 
net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2)

=== Port directory: 
/usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg


=== Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed
=== Aborting update

=== Update for openldap-sasl-client-2.4.39_2 failed
=== Aborting update

You have new mail.


This isn't, so far, OpenLDAP specific, on other systems without LDAP the update 
fails on
another port.

Oliver


signature.asc
Description: PGP signature

Re: pkg/ports system terribly messed up?

2014-09-30 Thread O. Hartmann

Am Tue, 30 Sep 2014 08:40:19 +0200 (CEST)
Trond Endrestøl trond.endres...@fagskolen.gjovik.no schrieb:

 On Tue, 30 Sep 2014 08:13+0200, O. Hartmann wrote:
 
  
  Hello.
  
  I just made the last update of the ports yesterday (I use portmaster -da 
  performing
  this task) and obviously or superficially everything went all right.
  
  I'm running on the boxes in question most recent CURRENT.
  
  On one system, a subsequent start of updating ports starts to freak out 
  when updateing
  lang/gcc: it loops over and over on some ports already updated, especially
  devel/binutils, but the port looping on isn't specific and varies.
  
  On every CURRENT box I tried this morning to update the ports again, I find 
  this
  frsutrating message (depends on installation, but it seems in principal the 
  same, only
  the affected ports in dependency chain varies):
  
   === Gathering distinfo list for installed ports
  
  === Starting check of installed ports for available updates
  === Launching child to update openldap-sasl-client-2.4.39_2 to
  openldap-sasl-client-2.4.40
  
  === All  openldap-sasl-client-2.4.39_2 (1/1)
  
  === Currently installed version: openldap-sasl-client-2.4.39_2
  === Port directory: /usr/ports/net/openldap24-sasl-client
  
  === Launching 'make checksum' for net/openldap24-sasl-client in 
  background
  === Gathering dependency list for net/openldap24-sasl-client from ports
  === Launching child to install 
  net/openldap24-sasl-client/../../ports-mgmt/pkg
  
  === All  openldap-sasl-client-2.4.39_2 
  net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2)
  
  === Port directory: 
  /usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg
  
  
  === Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed
  === Aborting update
  
  === Update for openldap-sasl-client-2.4.39_2 failed
  === Aborting update
  
  You have new mail.
  
  
  This isn't, so far, OpenLDAP specific, on other systems without LDAP the 
  update fails
  on another port.
  
  Oliver
 
 What happens if you manually upgrade ports-mgmt/pkg, assuming it's out 
 of date?

I tried this already, each port in particular, reinstalled via make clean 
reinstall
clean works fine. I did this with ports-mgnt/pkg and ports-mgmt/portmaster in 
the first
place.

 
 I've noticed running make missing from /usr/ports/ports-mgmt/pkg 
 produces some interesting results _only_ when pkg is up-to-date:
 
 trond@enterprise:/usr/ports/ports-mgmt/pkgmake missing
 /usr/ports/workdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.3.8/src/pkg-static: 
 not found
 *** [missing] Error code 127
 
 Stop in /usr/ports/ports-mgmt/pkg.
 
 Using portupgrade, I finally created a script to help me get past some 
 of the deficiency of the duo pkg and portupgrade. The script checks to 
 see if ports-mgmt/pkg needs an upgrade and upgrades pkg before 
 proceeding with the remaining outdated ports. As portupgrade doesn't 
 always properly install _new_ dependencies, my script also checks for 
 any missing ports and installs them prior to upgrading the outdated 
 ports. If anyone's interested, here's my script: 
 http://ximalas.info/~trond/create-zfs/canmount/upgrade-outdated-ports.sh
 


I'm running portmaster and an update of ports now on an Laptop with CURRENT 
that hasn't
been touched for two days by now and there the update runs quite well and 
passes through.
All boxes I ran an update of ports by yesterday fail!


signature.asc
Description: PGP signature

Re: WiFi 802.11/ac PCIe supported adaptor

Am Sun, 28 Sep 2014 00:22:09 +0200
Lars Engels lars.eng...@0x20.net schrieb:

 On Sat, Sep 27, 2014 at 02:38:30PM +0200, O. Hartmann wrote:
  
  I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and want 
  to
  replace it with an 802.11ac adaptor.
  
  Since I made very bad experiences with CURRENT and support of modest modern 
  hardware
  (Haswell CPU/Intel  7260 DualBand WiFi NIC), I'd like to ask here first.
  
  I found this PCIe adaptor card attractive:
  
  GigaByte Gigabyte GC-WB867D-I
  
  I can not find ad hoc the WLAN chip used on that specific card, but maybe 
  someone has
  experiences with that litte board.
 
 FreeBSD doensn't support 802.11ac, yet.

I'm bitter aware of that. This OS doesn't support the chipsets, even if they 
provide also
11a/g/n.

We have at our department now a bunch of Lenovo hardware, with Intels 7260 
chipset. The
laptops are now runninmg Ubuntu 14.0X something which obviously supports the 
WiFi chip.
I'm the last man standing with FreeBSD on my private Lenovo :-(


signature.asc
Description: PGP signature

Re: WiFi 802.11/ac PCIe supported adaptor

Am Sat, 27 Sep 2014 23:44:19 -0700
Kevin Oberman rkober...@gmail.com schrieb:

 On Sat, Sep 27, 2014 at 11:20 PM, Nathan Whitehorn nwhiteh...@freebsd.org
 wrote:
 
 
  On 09/27/14 23:06, O. Hartmann wrote:
 
  Am Sun, 28 Sep 2014 00:22:09 +0200
  Lars Engels lars.eng...@0x20.net schrieb:
 
   On Sat, Sep 27, 2014 at 02:38:30PM +0200, O. Hartmann wrote:
 
  I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and
  want to
  replace it with an 802.11ac adaptor.
 
  Since I made very bad experiences with CURRENT and support of modest
  modern hardware
  (Haswell CPU/Intel  7260 DualBand WiFi NIC), I'd like to ask here first.
 
  I found this PCIe adaptor card attractive:
 
  GigaByte Gigabyte GC-WB867D-I
 
  I can not find ad hoc the WLAN chip used on that specific card, but
  maybe someone has
  experiences with that litte board.
 
  FreeBSD doensn't support 802.11ac, yet.
 
  I'm bitter aware of that. This OS doesn't support the chipsets, even if
  they provide also
  11a/g/n.
 
  We have at our department now a bunch of Lenovo hardware, with Intels
  7260 chipset. The
  laptops are now runninmg Ubuntu 14.0X something which obviously supports
  the WiFi chip.
  I'm the last man standing with FreeBSD on my private Lenovo :-(
 
 
  This is a serious problem. I'm about ready to install Linux on my laptop
  as well just to get a usable system. Some kind of funding directed to a
  willing developer would be hugely valuable for the usability of the
  operating system on recent hardware. This is probably more important even
  than Haswell graphics since without a driver, Haswell is merely slow,
  whereas networking is completely broken.
  -Nathan
 
 
 While I don't yet have need of it and probably won't any time soon,
 Haswell support is becoming critical. It is getting more and more difficult
 to get boards with pre-Haswell processors, especially for laptops. It is
 still pretty easy to get supported WiFi cards for both desktops and
 laptops. I feel Haswell is getting to be a critical issue.
 
 VESA is available for Haswell systems, but it is very slow and too often
 the BIOS support of VESA is poor. Vendors want text mode for boot and such,
 but really have little interest in graphics as Intel has good native
 Windows drivers for them.Still waiting for Lenovo to fix VESA for my old
 Sandy Bridge laptop. I used VESA, which was badly broken, for almost a year
 waiting for KMS support, though I did get a recent BIOS update and have not
 tried VESA on it.
 --
 R. Kevin Oberman, Network Engineer, Retired
 E-mail: rkober...@gmail.com
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Some notes from my side.

I have personally a i3-3220 IvyBridge based server with iGPU HD2500, which 
doesn't work
properly on CURRENT and gets messed up with EFI and vt(). The screen is dark 
after
loading i915kms and the reason having a highres console is at hand. This is two 
year old
hardware! This server is now getting a new XEON CPU (same board, but with a 
professional
CPU i5-122X v2 with a P4000 iGPU). At another site I work for there are plans 
obtaining
also such toy-XEONs for power consumption reasons and the iGPU play an 
important role
here. And those systems are due to government funding for the next couple of 
years
definitely NOT outdated hardware from the past, they will be Haswell. So what 
now? As far
as I can say: maintaining a FreeBSD based server system on hardware that needs 
more than
one single compromise is cost-ineffective. I hate to judge things in terms of
cost-effectiveness, but the time, I spent now getting a crap iGPU on my laptop 
to work or
that on that IvyBridge is unaffordable!

The same is now with the laptops. Intels iGPU is getting stronger and stronger 
and
combined with their CPUs, there is rarely need for a dedicated GPU. We use 
OpenCL a lot,
so GPUs are welcome, even in notebooks. But not for FreeBSD, since OpenCL seems 
to be
Linux-domain only. Anyway, the new bunch of laptops we order is not the crap 
from
yesterday. Since my last Dell had to last for at least four years, I will order 
top of
the line hardware now - and I'm willing to wait for some weeks, two months with 
interim
solutions until FreeBSD would support the hardware we obtain, but compared to 
the past I
see chance. Not all of us want Linux, some use PC-BSD, some FreeBSD. The 
picture changes
now.

Networking wasn't an issue for me for years, but now, sitting on a pile of neat 
new
hardware of which FreeBSD can not make any serious use, let me rethink. 
Luckily, The
Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs 
agony I'm
able to swap the NIC with a piece of hardware that is supported. But it is 
additional
cost. I would happily do so - if there wouldn't be Linux support! I tried 
Ubuntu 14
something

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

Am Sat, 20 Sep 2014 21:21:46 +0200
Koop Mast k...@rainbow-runner.nl schrieb:

 On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote:
  Am Sat, 20 Sep 2014 19:15:30 +0200
  O. Hartmann ohart...@zedat.fu-berlin.de schrieb:
  
   Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT)
   Warren Block wbl...@wonkity.com schrieb:
   
On Sat, 20 Sep 2014, O. Hartmann wrote:

 Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
 Warren Block wbl...@wonkity.com schrieb:

 On Fri, 19 Sep 2014, O. Hartmann wrote:

 nVidia's BLOB from port x11/nvidia-driver seems to have problems in 
 FreeBSD
 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on 
 Lenovo
 ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with 
 integrated HD4600
 Intel iGPU and dedicated nVidia GT 740M (Optimus) working correctly.

 Optimus is supposed to be full Intel graphics plus an Nvidia GPU.  
 The
 extra GPU uses the same display memory and can be enabled to speed up
 the Intel graphics or disabled for power saving.  I don't know if
 versions where the Nvidia section is a full discrete video adapter 
 that
 can be used alone are still called Optimus.

 Some Optimus owners have reported being able to use the Intel drivers
 after disabling the Nvidia GPU in the BIOS or UEFI.  If an option to
 disable the Nvidia GPU is not present, some people have reported 
 success
 with an xorg.conf that uses only the intel driver and ignores the 
 Nvidia
 hardware.

 Thanks Warren.

 But this sounds even more frustrating now. I look around the web even 
 at
 Lenovo's support forum. Many people report the GT 740M nVidia adaptor 
 as a
 discrete adaptor with Optimus technology and everything sounds to me 
 like it
 can be selected exclusively. What you describes is that I definitely 
 need to
 use the HD4600 iGPU on FreeBSD in the first place since the nVidia 
 hardware is
 a kind of appendix to the HD4600.

Optimus started out that way, but they might use the same name now for 
models where the additional GPU is a full discrete adapter.
   
   I tried to retrieve  informations about the settings and implementations 
   in the
   lenovo E540, but I guess the only answer can be given by developer 
   documentation. I
   can not figure out how the GPU is attached to the system. The technical
   specifications do not mention the requirement of a iGPU and shared memory 
   - as
   Optimus would require.
   
   But extrapolating from that shit-covering public relations talking at 
   nVidia's
   site I guess the GT 740M is definitely a shared memory solution and 
   requires the
   presence of the iGPU. That would explain why the nvidia BLOB is detecting 
   the GPU,
   but can not find any physical display socket, not even the built-in LCD. 
   They're
   maybe wired all throught the Haswell's HD4600 iGPU? 
   

 Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't 
 work
 properly: it doesn't even start up and loading the intel driver 
 complains
 about a missing device
 - preceeded by a lot of /dev/dri errors. This indicates to me, in a 
 naiv manner,
 that this HD4600 isn't recodnized by the kernel, either. I do not see 
 any kind
 of vga0: entry in the kernel log when enabling Integrated Graphics 
 only in the
 laptop's UEFI/Firmware. When enabling nVidia Optimus, a recognized 
 vga0:
 device shows up.

Whoops, HD4600 is Haswell.  The intel driver on FreeBSD does not 
support 
Haswell video yet.
   
   
   I suspected that :-(
   
   Thanks anyway,
   
   Oliver
  
  Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find
  x11-drivers/xf86-video-nv, which covers old hardware and it is not 
  applicable to the
  GT 740M (complains, rightfully, that the found device isn't supported by 
  the nv
  driver).
  
  I face a mess here ... :-(
 
 It was removed, because we missing kernel support for the nouveau
 driver.
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Without nouveau driver, FreeBSD people do not have the slightes chance to play 
with
OpenCL/libclc on nVidia's hardware. I'm eager to watch the day when even the 
Radeon
driver gets ripped off due to lack of kernel support :-)


signature.asc
Description: PGP signature

Re: WiFi 802.11/ac PCIe supported adaptor

Am Sat, 27 Sep 2014 23:44:19 -0700
Kevin Oberman rkober...@gmail.com schrieb:

 On Sat, Sep 27, 2014 at 11:20 PM, Nathan Whitehorn nwhiteh...@freebsd.org
 wrote:
 
 
  On 09/27/14 23:06, O. Hartmann wrote:
 
  Am Sun, 28 Sep 2014 00:22:09 +0200
  Lars Engels lars.eng...@0x20.net schrieb:
 
   On Sat, Sep 27, 2014 at 02:38:30PM +0200, O. Hartmann wrote:
 
  I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and
  want to
  replace it with an 802.11ac adaptor.
 
  Since I made very bad experiences with CURRENT and support of modest
  modern hardware
  (Haswell CPU/Intel  7260 DualBand WiFi NIC), I'd like to ask here first.
 
  I found this PCIe adaptor card attractive:
 
  GigaByte Gigabyte GC-WB867D-I
 
  I can not find ad hoc the WLAN chip used on that specific card, but
  maybe someone has
  experiences with that litte board.
 
  FreeBSD doensn't support 802.11ac, yet.
 
  I'm bitter aware of that. This OS doesn't support the chipsets, even if
  they provide also
  11a/g/n.
 
  We have at our department now a bunch of Lenovo hardware, with Intels
  7260 chipset. The
  laptops are now runninmg Ubuntu 14.0X something which obviously supports
  the WiFi chip.
  I'm the last man standing with FreeBSD on my private Lenovo :-(
 
 
  This is a serious problem. I'm about ready to install Linux on my laptop
  as well just to get a usable system. Some kind of funding directed to a
  willing developer would be hugely valuable for the usability of the
  operating system on recent hardware. This is probably more important even
  than Haswell graphics since without a driver, Haswell is merely slow,
  whereas networking is completely broken.
  -Nathan
 
 
 While I don't yet have need of it and probably won't any time soon,
 Haswell support is becoming critical. It is getting more and more difficult
 to get boards with pre-Haswell processors, especially for laptops. It is
 still pretty easy to get supported WiFi cards for both desktops and
 laptops. I feel Haswell is getting to be a critical issue.

I use the xf86-video-scfb driver, VESA driver doesn' coop with the resolution 
of my
display (called Full HD, 1980x1080 pixel). VESA complains about not know 
resolution when
starting.

The SCFB is unusable. The i5-4200M CPU has enough stamina to do well, but when 
it comes
to video/desktop/graphics under load, the graphics is rendered unusable. 


The laptop is not productive and an expensive heap of plastic, silica and metal 
with
FreeBSD that way.

 
 VESA is available for Haswell systems, but it is very slow and too often
 the BIOS support of VESA is poor. Vendors want text mode for boot and such,
 but really have little interest in graphics as Intel has good native
 Windows drivers for them.Still waiting for Lenovo to fix VESA for my old
 Sandy Bridge laptop. I used VESA, which was badly broken, for almost a year
 waiting for KMS support, though I did get a recent BIOS update and have not
 tried VESA on it.
 --
 R. Kevin Oberman, Network Engineer, Retired
 E-mail: rkober...@gmail.com
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



signature.asc
Description: PGP signature

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

Am Sun, 28 Sep 2014 12:05:36 +0200
Jan Kokemüller jan.kokemuel...@gmail.com schrieb:

On 28.09.2014 11:41, O. Hartmann wrote:
Without nouveau driver, FreeBSD people do not have the slightes chance to
play with
OpenCL/libclc on nVidia's hardware.

Some time in the past it was possible to run CUDA/OpenCL Linux binaries
with the Nvidia driver in Linux emulation mode on FreeBSD:

https://web.archive.org/web/20121015180221/http://blogs.freebsdish.org/jhb/2010/07/20/using-cuda-with-the-native-freebsdamd64-nvidia-driver

Not sure if that still works though.

Well, I went through this stuff that time and from the date, you can see its
four years in
the past! There was also thast promising thing from Pathscale, HMPC ast
promising thing
from Pathscale, HMPC or similar, now OpenACC. But at the end it was a
dream-bubble.

And as far as I know: even the Linuxulator is ways behind the recent
development and
still 32Bit (ancient, so to speak). I do not want myself having lots of
outdated hard-
and software running and developing on outdated platforms.

And it is even worse: some new technology utilizing LLVM, libCLC, most recent
MESA libs
and the most recent opensource graphics driver provide rudimentary OpenCL
support for the
GPU - but as I stated in the thread concerning the missing WiFi Intel 7260
support -
FreeBSD hasn't even the xf86-video-nouveau driver anymore which is supposed to
work best
in that scenario.

I had very longish discussions in 2010 about this subject - from a naiv
non-developer
point of view. I was always told, FreeBSD is an OS for servers and we all know,
that
servers do not rely on graphics hardware that much as it is important for
graphics
workstations and not at least desktop machines.
But what we faced five years ago in science regarding the rapid development of
OpenCL and
GPGPU showed me very ckearly that GPU hardware is becoming dramatically
important. With
AMD providing powerful iGPUs and now Intel doing the same, number crunching
isn't the
domain of physicists and numerical geeks anymore, GEGL starts to incorporate
OpenCL and
GIMP is about to utilize the GPU as well. BLENDER is utilizing CUDA in Linux
and I guess
OpenCL is also on the way. And if this isn't convincing: I read about cloud
computing
with massively parallelized TESLA backends, a typical domain of dump and
unexciting
hardware and their operating systems. And guess what? The key is obviously the
support of
the graphical functionality, not necessarily the X11 desktop it self.

The project that time in 2010, where we were supposed and inclined to use
FreeBSD as the
development platform for a highly parallelized application for planetary
science imaging
was then based on OpenSUSE and Ubuntu Linux and OpenCL. From a simple naive
point of
view, I can not express deeply enough how excited I was when I saw, how fast the
combination of CPUs and GPUs using OpenCL coding could be. What was done in an
expensive
and professional manner on expensive hardware was developed and tested on
cheaper gaming
riggs and even on those platforms the boost was tremendous. But not with
FreeBSD! All
Linux.

I think FreeBSD will find its niche in the embedded networking hardware market
as long as
it still has the faster network stack. But since the Linux folks started to
attack this
domain in a disgusting PR-ish way, I doubt that even this will last long. Or
FreeBSD will
show its power with colourless databases.

One of the reasons why FreeBSD is still on top of the list of the OSes is the
fact of its
deep ZFS incorporation - as Matthew Dillon once said: it saved FreeBSD's ass.
Well,
Dillon developed then HAMMER and showed once again, that the effords in the BSD
field are
spread all over the area and thinning out as times passes. For FreeBSD, the day
when Linux
will have its ZFS in-kernel will be devastating - I guess.

signature.asc
Description: PGP signature

WiFi 802.11/ac PCIe supported adaptor

2014-09-27 Thread O. Hartmann


I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and want to 
replace it
with an 802.11ac adaptor.

Since I made very bad experiences with CURRENT and support of modest modern 
hardware
(Haswell CPU/Intel  7260 DualBand WiFi NIC), I'd like to ask here first.

I found this PCIe adaptor card attractive:

GigaByte Gigabyte GC-WB867D-I

I can not find ad hoc the WLAN chip used on that specific card, but maybe 
someone has
experiences with that litte board.

Thanks in advance,
Oliver


signature.asc
Description: PGP signature

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

2014-09-27 Thread O. Hartmann

Am Sat, 20 Sep 2014 09:21:34 -0500
Larry Rosenman l...@lerctr.org schrieb:

 On 2014-09-20 09:10, O. Hartmann wrote:
  Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
  Warren Block wbl...@wonkity.com schrieb:
  
  On Fri, 19 Sep 2014, O. Hartmann wrote:
  
   nVidia's BLOB from port x11/nvidia-driver seems to have problems in 
   FreeBSD
   11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo 
   ThinkPad
   Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 
   Intel iGPU and
   dedicated nVidia GT 740M (Optimus) working correctly.
  
  Optimus is supposed to be full Intel graphics plus an Nvidia GPU.  The
  extra GPU uses the same display memory and can be enabled to speed up
  the Intel graphics or disabled for power saving.  I don't know if
  versions where the Nvidia section is a full discrete video adapter 
  that
  can be used alone are still called Optimus.
  
  Some Optimus owners have reported being able to use the Intel drivers
  after disabling the Nvidia GPU in the BIOS or UEFI.  If an option to
  disable the Nvidia GPU is not present, some people have reported 
  success
  with an xorg.conf that uses only the intel driver and ignores the 
  Nvidia
  hardware.
  
  Thanks Warren.
  
  But this sounds even more frustrating now. I look around the web even
  at Lenovo's support
  forum. Many people report the GT 740M nVidia adaptor as a discrete
  adaptor with Optimus
  technology and everything sounds to me like it can be selected
  exclusively. What you
  describes is that I definitely need to use the HD4600 iGPU on FreeBSD
  in the first place
  since the nVidia hardware is a kind of appendix to the HD4600.
  
  Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't
  work properly: it
  doesn't even start up and loading the intel driver complains about a
  missing device -
  preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv
  manner, that this
  HD4600 isn't recodnized by the kernel, either. I do not see any kind
  of vga0: entry in
  the kernel log when enabling Integrated Graphics only in the
  laptop's UEFI/Firmware.
  When enabling nVidia Optimus, a recognized vga0: device shows up.
  
  From my server, equipted with a IvyBridge i3-class CPU with integrated
  iGPU, I even get
  this message from 11.0-CURRENT:
  
  vgapci0@pci0:0:2:0: class=0x03 card=0x01521849 chip=0x01528086
  rev=0x09 hdr=0x00
  vendor = 'Intel Corporation'
  device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics 
  Controller'
  class  = display
  subclass   = VGA
  bar   [10] = type Memory, range 64, base 0xf780, size 4194304, 
  enabled
  bar   [18] = type Prefetchable Memory, range 64, base 0xe000,
  size 268435456,
  enabled bar   [20] = type I/O Port, range 32, base 0xf000, size 64, 
  enabled
  cap 05[90] = MSI supports 1 message
  cap 01[d0] = powerspec 2  supports D0 D3  current D0
  cap 13[a4] = PCI Advanced Features: FLR TP
  
  
  The very same CURRENT (most recent as I built world on all system 
  today) doesn't
  recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems
  impossible to me that people
  can report having this GPU working if even the most recent FreeBSD
  CURRENT doesn't
  recognize it.
 for the record, on my Thinkpad W520+Docking Station, I get two HDMI / 
 DVI outputs off the Nvidia GPU, in addition to the
 Intel graphics on the local LCD.   This is under Windows, but.
 
 

Just for the record.

Another box, running as a server with CURRENT on-top of a Intel(R) Core(TM) 
i3-3220 CPU
with Ivy-Bridge HD2500 graphics, crashes/blanks screen when going into graphics 
mode with
vt() (having kernel modules drm2 and i915kms already loaded via loader.conf).

This hardware is now for two years in use and the CPU is much older.

The CPU is about to be replaced by a XEON E3-1245 v2 with P4000 iGPU graphics 
(only). At
this moment, I'm highly afraid of having hardware that is not working even with 
CURRENT.


signature.asc
Description: PGP signature

Re: WiFi 802.11/ac PCIe supported adaptor

2014-09-27 Thread O. Hartmann

Am Sat, 27 Sep 2014 08:41:56 -0600 (MDT)
Warren Block wbl...@wonkity.com schrieb:

 On Sat, 27 Sep 2014, O. Hartmann wrote:
 
 
  I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and want 
  to
  replace it with an 802.11ac adaptor.
 
  Since I made very bad experiences with CURRENT and support of modest modern 
  hardware
  (Haswell CPU/Intel  7260 DualBand WiFi NIC), I'd like to ask here first.
 
  I found this PCIe adaptor card attractive:
 
  GigaByte Gigabyte GC-WB867D-I
 
  I can not find ad hoc the WLAN chip used on that specific card, but maybe 
  someone has
  experiences with that litte board.
 
 Newegg reviews say this is an Intel 7260HMW:
 http://www.newegg.com/Product/Product.aspx?Item=N82E16813995032Tpk=N82E16813995032
 
 I don't know if that is supported on FreeBSD yet.
 
 PCIe to mini-PCIe adapters like that can be found separately, allowing 
 the use of any mini-PCIe card.  I've successfully tested an Atheros 
 AR9280 card in one.

Thats a pity. I have already this WiFi adaptor in a Lenovo E540 laptop and it 
isn't
supported by CURRENT. Some rumours say it is supposed to be supported by iwl() 
in the
future. 


signature.asc
Description: PGP signature

/boot/loader.efi and buildkernel

2014-09-23 Thread O. Hartmann


Modules and kernel are built when running make buildkernel, but the other 
contents
of /boot/ aren't. How can I manually - and separately - build the loader,
especially /boot/loader.efi?

I realized that building loader.efi with any kind of optimization beyond 
debugging- or
close-to-debugging level ends up in an unloadable loader.efi on Haswell CPUs 
(IvyBridge
and C2D seem to be unaffected). The system in question is the most recent 
CURRENT,
compiled with system's CLANG 3.4.1.

Regards,
Oliver


signature.asc
Description: PGP signature

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

2014-09-21 Thread O. Hartmann

Am Sat, 20 Sep 2014 09:21:34 -0500
Larry Rosenman l...@lerctr.org schrieb:

 On 2014-09-20 09:10, O. Hartmann wrote:
  Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
  Warren Block wbl...@wonkity.com schrieb:
  
  On Fri, 19 Sep 2014, O. Hartmann wrote:
  
   nVidia's BLOB from port x11/nvidia-driver seems to have problems in 
   FreeBSD
   11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo 
   ThinkPad
   Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 
   Intel iGPU and
   dedicated nVidia GT 740M (Optimus) working correctly.
  
  Optimus is supposed to be full Intel graphics plus an Nvidia GPU.  The
  extra GPU uses the same display memory and can be enabled to speed up
  the Intel graphics or disabled for power saving.  I don't know if
  versions where the Nvidia section is a full discrete video adapter 
  that
  can be used alone are still called Optimus.
  
  Some Optimus owners have reported being able to use the Intel drivers
  after disabling the Nvidia GPU in the BIOS or UEFI.  If an option to
  disable the Nvidia GPU is not present, some people have reported 
  success
  with an xorg.conf that uses only the intel driver and ignores the 
  Nvidia
  hardware.
  
  Thanks Warren.
  
  But this sounds even more frustrating now. I look around the web even
  at Lenovo's support
  forum. Many people report the GT 740M nVidia adaptor as a discrete
  adaptor with Optimus
  technology and everything sounds to me like it can be selected
  exclusively. What you
  describes is that I definitely need to use the HD4600 iGPU on FreeBSD
  in the first place
  since the nVidia hardware is a kind of appendix to the HD4600.
  
  Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't
  work properly: it
  doesn't even start up and loading the intel driver complains about a
  missing device -
  preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv
  manner, that this
  HD4600 isn't recodnized by the kernel, either. I do not see any kind
  of vga0: entry in
  the kernel log when enabling Integrated Graphics only in the
  laptop's UEFI/Firmware.
  When enabling nVidia Optimus, a recognized vga0: device shows up.
  
  From my server, equipted with a IvyBridge i3-class CPU with integrated
  iGPU, I even get
  this message from 11.0-CURRENT:
  
  vgapci0@pci0:0:2:0: class=0x03 card=0x01521849 chip=0x01528086
  rev=0x09 hdr=0x00
  vendor = 'Intel Corporation'
  device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics 
  Controller'
  class  = display
  subclass   = VGA
  bar   [10] = type Memory, range 64, base 0xf780, size 4194304, 
  enabled
  bar   [18] = type Prefetchable Memory, range 64, base 0xe000,
  size 268435456,
  enabled bar   [20] = type I/O Port, range 32, base 0xf000, size 64, 
  enabled
  cap 05[90] = MSI supports 1 message
  cap 01[d0] = powerspec 2  supports D0 D3  current D0
  cap 13[a4] = PCI Advanced Features: FLR TP
  
  
  The very same CURRENT (most recent as I built world on all system 
  today) doesn't
  recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems
  impossible to me that people
  can report having this GPU working if even the most recent FreeBSD
  CURRENT doesn't
  recognize it.
 for the record, on my Thinkpad W520+Docking Station, I get two HDMI / 
 DVI outputs off the Nvidia GPU, in addition to the
 Intel graphics on the local LCD.   This is under Windows, but.
 
 

Fiddling around longer, I realizes now a console message popping up whenever I 
try to
start the nVidia GPU. I have ignored that the whole time:

Sep 21 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: 
Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
Sep 21
09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
type
mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
Sep 21
09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
type
mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
Sep 21
09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
type
mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
Sep 21
09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
type
mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
Sep 21
09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
type
mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
Sep 21
09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
type
mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
Sep 21
09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
type
mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
Sep 21
09

Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI

Am Mon, 15 Sep 2014 18:19:32 -0700
Kevin Oberman rkober...@gmail.com schrieb:

 On Mon, Sep 15, 2014 at 2:38 PM, O. Hartmann ohart...@zedat.fu-berlin.de
 wrote:
 
 
  Trying to install and run FreeBSD 11.0-CURRENT
  (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Lenovo
  E540 notebook
  fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The NIC
  shows up as
  active and with carrier when issuing ifconfig re0.
 
  From a desktop machine, I tried to ping the system in question and I get a
  result with
  missing packets:
 
  ping: sendto: Host is down
  ping: sendto: Host is down
  ping: sendto: Host is down
  64 bytes from 192.168.0.130: icmp_seq=26 ttl=64 time=0.114 ms
  64 bytes from 192.168.0.130: icmp_seq=41 ttl=64 time=0.130 ms
  64 bytes from 192.168.0.130: icmp_seq=60 ttl=64 time=0.119 ms
  64 bytes from 192.168.0.130: icmp_seq=80 ttl=64 time=0.119 ms
  64 bytes from 192.168.0.130: icmp_seq=100 ttl=64 time=0.105 ms
  64 bytes from 192.168.0.130: icmp_seq=116 ttl=64 time=0.135 ms
  64 bytes from 192.168.0.130: icmp_seq=136 ttl=64 time=0.091 ms
 
  DHCP configuration fails, since no DHCP offer is discovered.
 
  I swapped the switches, the cabling and I had always the same results. I
  used another
  Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) and
  that system
  gets DHCP offer and is online.
 
  Since the notebook is brandnew, the last thing I'll suspect is a
  defective NIC, so I'll
  ask whether this phenomenon is known - or, if not, the results
  definititely would
  indicate a broken NIC.
 
  Another point is the WiFI adaptor. This notebook is supposed to have a
  WiFi NIC, but it
  doesn't get revealed by FreeBSD (I tried iwn/iwi without success).
 
  pciconf output below, sorry for the messy shape, it is a copy-and-paste
  from that immature
  vt() terminal.
 
  Has anyone successfully installed that type of Notebook with FreeBSD
  CURRENT using NIC
  and Wifi?
 
  Please CC me.
 
 
  Regards
  oh
 
 
  [...]
 
  none1@pci0:3:0:0:   class=0xff card=0x502817aa chip=0x522710ec
  rev=0x01 hdr=0x00
 
 
  vendor = 'Realtek Semiconductor Co., Ltd.'
 
 
  bar   [10] = type Memory, range 32, base 0xf1e0, size 4096, enabled
 
 
  cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
 
 
  cap 05[50] = MSI supports 1 message, 64 bit
 
 
  cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1)
 
 
   speed 2.5(2.5) ASPM L0s/L1(L0s/L1)
 
 
  ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected
 
 
  ecap 0003[140] = Serial 1 0001004ce000
 
 
  re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10
  hdr=0x00
 
 
  subclass   = ethernet
 
 
  cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current
  D0
  di sabled(L0s/L1)
 
 
  cap 11[b0] = MSI-X supports 4 messages, enabled
 
  ecap 0001[100] = AER 2 0 fatal 0 non-fatal 4 corrected
 
 
 
  ecap 001e[178] = unknown 1
 
 
  class  = network
 
 
  cap 05[d0] = MSI supports 1 message, 64 bit
 
 
  ecap 0003[140] = Serial 1 ac7ba1a06fd6
 
 
 I can't comment on the WiFi, I have little Asus box using an 8111/8168B and
 it works fine with the driver in 10.1-BETA. The driver in 10.0 recognizes
 the device, but did not work. I do notice that your NIC has a rev of 0x10
 while mine is 0x0c.
 --
 Kevin Oberman, Network Engineer, Retired

I tried a 10.1-BETA also and it shows the very same symptomes as in 
11.0-CURRENT. As
Guido Falsi stated later in this thread, the device gets recognized but is 
inoperable
after initialized and setup by the OS until the administrator takes some 
strange actions.
In Guido's case a setting/resetting of NIC features helps, in my case I have to 
bring
down the device first via ifconfig re0 down and then bring it up. After that, 
the NIC
works as expected. This seems clearly to be a bug in the driver code and it 
might indeed
have to do something with a new revision used, but the NIC is since at least a 
year on
the market and floating around (my laptop was manufactured in April of this 
year).

Well, I hope this report doesn't get lost, so I filed a PR.

Oliver



signature.asc
Description: PGP signature

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
Warren Block wbl...@wonkity.com schrieb:

 On Fri, 19 Sep 2014, O. Hartmann wrote:
 
  nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD
  11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo 
  ThinkPad Edge
  E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU 
  and
  dedicated nVidia GT 740M (Optimus) working correctly.
 
 Optimus is supposed to be full Intel graphics plus an Nvidia GPU.  The 
 extra GPU uses the same display memory and can be enabled to speed up 
 the Intel graphics or disabled for power saving.  I don't know if 
 versions where the Nvidia section is a full discrete video adapter that 
 can be used alone are still called Optimus.
 
 Some Optimus owners have reported being able to use the Intel drivers 
 after disabling the Nvidia GPU in the BIOS or UEFI.  If an option to 
 disable the Nvidia GPU is not present, some people have reported success 
 with an xorg.conf that uses only the intel driver and ignores the Nvidia 
 hardware.

Thanks Warren.

But this sounds even more frustrating now. I look around the web even at 
Lenovo's support
forum. Many people report the GT 740M nVidia adaptor as a discrete adaptor with 
Optimus
technology and everything sounds to me like it can be selected exclusively. 
What you
describes is that I definitely need to use the HD4600 iGPU on FreeBSD in the 
first place
since the nVidia hardware is a kind of appendix to the HD4600.

Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work 
properly: it
doesn't even start up and loading the intel driver complains about a missing 
device -
preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv manner, 
that this
HD4600 isn't recodnized by the kernel, either. I do not see any kind of vga0: 
entry in
the kernel log when enabling Integrated Graphics only in the laptop's 
UEFI/Firmware.
When enabling nVidia Optimus, a recognized vga0: device shows up.

From my server, equipted with a IvyBridge i3-class CPU with integrated iGPU, I 
even get
this message from 11.0-CURRENT:

vgapci0@pci0:0:2:0: class=0x03 card=0x01521849 chip=0x01528086 rev=0x09 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller'
class  = display
subclass   = VGA
bar   [10] = type Memory, range 64, base 0xf780, size 4194304, enabled
bar   [18] = type Prefetchable Memory, range 64, base 0xe000, size 
268435456,
enabled bar   [20] = type I/O Port, range 32, base 0xf000, size 64, enabled
cap 05[90] = MSI supports 1 message 
cap 01[d0] = powerspec 2  supports D0 D3  current D0
cap 13[a4] = PCI Advanced Features: FLR TP


The very same CURRENT (most recent as I built world on all system today) doesn't
recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems impossible to me 
that people
can report having this GPU working if even the most recent FreeBSD CURRENT 
doesn't
recognize it.


signature.asc
Description: PGP signature

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

Am Sat, 20 Sep 2014 16:10:12 +0200
O. Hartmann ohart...@zedat.fu-berlin.de schrieb:

 Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
 Warren Block wbl...@wonkity.com schrieb:
 
  On Fri, 19 Sep 2014, O. Hartmann wrote:
  
   nVidia's BLOB from port x11/nvidia-driver seems to have problems in 
   FreeBSD
   11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo 
   ThinkPad
   Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel 
   iGPU and
   dedicated nVidia GT 740M (Optimus) working correctly.
  
  Optimus is supposed to be full Intel graphics plus an Nvidia GPU.  The 
  extra GPU uses the same display memory and can be enabled to speed up 
  the Intel graphics or disabled for power saving.  I don't know if 
  versions where the Nvidia section is a full discrete video adapter that 
  can be used alone are still called Optimus.
  
  Some Optimus owners have reported being able to use the Intel drivers 
  after disabling the Nvidia GPU in the BIOS or UEFI.  If an option to 
  disable the Nvidia GPU is not present, some people have reported success 
  with an xorg.conf that uses only the intel driver and ignores the Nvidia 
  hardware.
 
 Thanks Warren.
 
 But this sounds even more frustrating now. I look around the web even at 
 Lenovo's
 support forum. Many people report the GT 740M nVidia adaptor as a discrete 
 adaptor with
 Optimus technology and everything sounds to me like it can be selected 
 exclusively.
 What you describes is that I definitely need to use the HD4600 iGPU on 
 FreeBSD in the
 first place since the nVidia hardware is a kind of appendix to the HD4600.
 
 Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work 
 properly: it
 doesn't even start up and loading the intel driver complains about a 
 missing device -
 preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv 
 manner, that this
 HD4600 isn't recodnized by the kernel, either. I do not see any kind of vga0: 
 entry in
 the kernel log when enabling Integrated Graphics only in the laptop's 
 UEFI/Firmware.
 When enabling nVidia Optimus, a recognized vga0: device shows up.
 
 From my server, equipted with a IvyBridge i3-class CPU with integrated iGPU, 
 I even get
 this message from 11.0-CURRENT:
 
 vgapci0@pci0:0:2:0: class=0x03 card=0x01521849 chip=0x01528086 
 rev=0x09 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller'
 class  = display
 subclass   = VGA
 bar   [10] = type Memory, range 64, base 0xf780, size 4194304, enabled
 bar   [18] = type Prefetchable Memory, range 64, base 0xe000, size 
 268435456,
 enabled bar   [20] = type I/O Port, range 32, base 0xf000, size 64, enabled
 cap 05[90] = MSI supports 1 message 
 cap 01[d0] = powerspec 2  supports D0 D3  current D0
 cap 13[a4] = PCI Advanced Features: FLR TP
 
 
 The very same CURRENT (most recent as I built world on all system today) 
 doesn't
 recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems impossible to me 
 that
 people can report having this GPU working if even the most recent FreeBSD 
 CURRENT
 doesn't recognize it.

Sorry, on the laptop in question the integrated HD4600 does show up as a vga0: 
device in
the pciconf-listing (it is very early and I stoped looking at the very end ...).


signature.asc
Description: PGP signature

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT)
Warren Block wbl...@wonkity.com schrieb:

 On Sat, 20 Sep 2014, O. Hartmann wrote:
 
  Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
  Warren Block wbl...@wonkity.com schrieb:
 
  On Fri, 19 Sep 2014, O. Hartmann wrote:
 
  nVidia's BLOB from port x11/nvidia-driver seems to have problems in 
  FreeBSD
  11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo 
  ThinkPad
  Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel 
  iGPU and
  dedicated nVidia GT 740M (Optimus) working correctly.
 
  Optimus is supposed to be full Intel graphics plus an Nvidia GPU.  The
  extra GPU uses the same display memory and can be enabled to speed up
  the Intel graphics or disabled for power saving.  I don't know if
  versions where the Nvidia section is a full discrete video adapter that
  can be used alone are still called Optimus.
 
  Some Optimus owners have reported being able to use the Intel drivers
  after disabling the Nvidia GPU in the BIOS or UEFI.  If an option to
  disable the Nvidia GPU is not present, some people have reported success
  with an xorg.conf that uses only the intel driver and ignores the Nvidia
  hardware.
 
  Thanks Warren.
 
  But this sounds even more frustrating now. I look around the web even at 
  Lenovo's
  support forum. Many people report the GT 740M nVidia adaptor as a discrete 
  adaptor
  with Optimus technology and everything sounds to me like it can be selected
  exclusively. What you describes is that I definitely need to use the HD4600 
  iGPU on
  FreeBSD in the first place since the nVidia hardware is a kind of 
  appendix to the
  HD4600.
 
 Optimus started out that way, but they might use the same name now for 
 models where the additional GPU is a full discrete adapter.

I tried to retrieve  informations about the settings and implementations in the 
lenovo
E540, but I guess the only answer can be given by developer documentation. I 
can not
figure out how the GPU is attached to the system. The technical specifications 
do not
mention the requirement of a iGPU and shared memory - as Optimus would require.

But extrapolating from that shit-covering public relations talking at 
nVidia's site I
guess the GT 740M is definitely a shared memory solution and requires the 
presence of
the iGPU. That would explain why the nvidia BLOB is detecting the GPU, but can 
not find
any physical display socket, not even the built-in LCD. They're maybe wired all 
throught
the Haswell's HD4600 iGPU? 

 
  Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work 
  properly: it
  doesn't even start up and loading the intel driver complains about a 
  missing device
  - preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv 
  manner, that
  this HD4600 isn't recodnized by the kernel, either. I do not see any kind 
  of vga0:
  entry in the kernel log when enabling Integrated Graphics only in the 
  laptop's
  UEFI/Firmware. When enabling nVidia Optimus, a recognized vga0: device 
  shows up.
 
 Whoops, HD4600 is Haswell.  The intel driver on FreeBSD does not support 
 Haswell video yet.


I suspected that :-(

Thanks anyway,

Oliver


signature.asc
Description: PGP signature

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

Am Sat, 20 Sep 2014 19:15:30 +0200
O. Hartmann ohart...@zedat.fu-berlin.de schrieb:

 Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT)
 Warren Block wbl...@wonkity.com schrieb:
 
  On Sat, 20 Sep 2014, O. Hartmann wrote:
  
   Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
   Warren Block wbl...@wonkity.com schrieb:
  
   On Fri, 19 Sep 2014, O. Hartmann wrote:
  
   nVidia's BLOB from port x11/nvidia-driver seems to have problems in 
   FreeBSD
   11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo 
   ThinkPad
   Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 
   Intel iGPU and
   dedicated nVidia GT 740M (Optimus) working correctly.
  
   Optimus is supposed to be full Intel graphics plus an Nvidia GPU.  The
   extra GPU uses the same display memory and can be enabled to speed up
   the Intel graphics or disabled for power saving.  I don't know if
   versions where the Nvidia section is a full discrete video adapter that
   can be used alone are still called Optimus.
  
   Some Optimus owners have reported being able to use the Intel drivers
   after disabling the Nvidia GPU in the BIOS or UEFI.  If an option to
   disable the Nvidia GPU is not present, some people have reported success
   with an xorg.conf that uses only the intel driver and ignores the Nvidia
   hardware.
  
   Thanks Warren.
  
   But this sounds even more frustrating now. I look around the web even at 
   Lenovo's
   support forum. Many people report the GT 740M nVidia adaptor as a 
   discrete adaptor
   with Optimus technology and everything sounds to me like it can be 
   selected
   exclusively. What you describes is that I definitely need to use the 
   HD4600 iGPU on
   FreeBSD in the first place since the nVidia hardware is a kind of 
   appendix to the
   HD4600.
  
  Optimus started out that way, but they might use the same name now for 
  models where the additional GPU is a full discrete adapter.
 
 I tried to retrieve  informations about the settings and implementations in 
 the lenovo
 E540, but I guess the only answer can be given by developer documentation. I 
 can not
 figure out how the GPU is attached to the system. The technical 
 specifications do not
 mention the requirement of a iGPU and shared memory - as Optimus would 
 require.
 
 But extrapolating from that shit-covering public relations talking at 
 nVidia's site I
 guess the GT 740M is definitely a shared memory solution and requires the 
 presence of
 the iGPU. That would explain why the nvidia BLOB is detecting the GPU, but 
 can not find
 any physical display socket, not even the built-in LCD. They're maybe wired 
 all throught
 the Haswell's HD4600 iGPU? 
 
  
   Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work 
   properly:
   it doesn't even start up and loading the intel driver complains about a 
   missing
   device
   - preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv 
   manner,
   that this HD4600 isn't recodnized by the kernel, either. I do not see any 
   kind of
   vga0: entry in the kernel log when enabling Integrated Graphics only in 
   the
   laptop's UEFI/Firmware. When enabling nVidia Optimus, a recognized 
   vga0: device
   shows up.
  
  Whoops, HD4600 is Haswell.  The intel driver on FreeBSD does not support 
  Haswell video yet.
 
 
 I suspected that :-(
 
 Thanks anyway,
 
 Oliver

Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find
x11-drivers/xf86-video-nv, which covers old hardware and it is not applicable 
to the GT
740M (complains, rightfully, that the found device isn't supported by the nv 
driver).

I face a mess here ... :-(


signature.asc
Description: PGP signature

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

Am Sat, 20 Sep 2014 21:21:46 +0200
Koop Mast k...@rainbow-runner.nl schrieb:

 On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote:
  Am Sat, 20 Sep 2014 19:15:30 +0200
  O. Hartmann ohart...@zedat.fu-berlin.de schrieb:
  
   Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT)
   Warren Block wbl...@wonkity.com schrieb:
   
On Sat, 20 Sep 2014, O. Hartmann wrote:

 Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
 Warren Block wbl...@wonkity.com schrieb:

 On Fri, 19 Sep 2014, O. Hartmann wrote:

 nVidia's BLOB from port x11/nvidia-driver seems to have problems in 
 FreeBSD
 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on 
 Lenovo
 ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with 
 integrated HD4600
 Intel iGPU and dedicated nVidia GT 740M (Optimus) working correctly.

 Optimus is supposed to be full Intel graphics plus an Nvidia GPU.  
 The
 extra GPU uses the same display memory and can be enabled to speed up
 the Intel graphics or disabled for power saving.  I don't know if
 versions where the Nvidia section is a full discrete video adapter 
 that
 can be used alone are still called Optimus.

 Some Optimus owners have reported being able to use the Intel drivers
 after disabling the Nvidia GPU in the BIOS or UEFI.  If an option to
 disable the Nvidia GPU is not present, some people have reported 
 success
 with an xorg.conf that uses only the intel driver and ignores the 
 Nvidia
 hardware.

 Thanks Warren.

 But this sounds even more frustrating now. I look around the web even 
 at
 Lenovo's support forum. Many people report the GT 740M nVidia adaptor 
 as a
 discrete adaptor with Optimus technology and everything sounds to me 
 like it
 can be selected exclusively. What you describes is that I definitely 
 need to
 use the HD4600 iGPU on FreeBSD in the first place since the nVidia 
 hardware is
 a kind of appendix to the HD4600.

Optimus started out that way, but they might use the same name now for 
models where the additional GPU is a full discrete adapter.
   
   I tried to retrieve  informations about the settings and implementations 
   in the
   lenovo E540, but I guess the only answer can be given by developer 
   documentation. I
   can not figure out how the GPU is attached to the system. The technical
   specifications do not mention the requirement of a iGPU and shared memory 
   - as
   Optimus would require.
   
   But extrapolating from that shit-covering public relations talking at 
   nVidia's
   site I guess the GT 740M is definitely a shared memory solution and 
   requires the
   presence of the iGPU. That would explain why the nvidia BLOB is detecting 
   the GPU,
   but can not find any physical display socket, not even the built-in LCD. 
   They're
   maybe wired all throught the Haswell's HD4600 iGPU? 
   

 Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't 
 work
 properly: it doesn't even start up and loading the intel driver 
 complains
 about a missing device
 - preceeded by a lot of /dev/dri errors. This indicates to me, in a 
 naiv manner,
 that this HD4600 isn't recodnized by the kernel, either. I do not see 
 any kind
 of vga0: entry in the kernel log when enabling Integrated Graphics 
 only in the
 laptop's UEFI/Firmware. When enabling nVidia Optimus, a recognized 
 vga0:
 device shows up.

Whoops, HD4600 is Haswell.  The intel driver on FreeBSD does not 
support 
Haswell video yet.
   
   
   I suspected that :-(
   
   Thanks anyway,
   
   Oliver
  
  Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find
  x11-drivers/xf86-video-nv, which covers old hardware and it is not 
  applicable to the
  GT 740M (complains, rightfully, that the found device isn't supported by 
  the nv
  driver).
  
  I face a mess here ... :-(
 
 It was removed, because we missing kernel support for the nouveau
 driver.


So, every new GPU not supported by xf86-video-nv has to use nVidia's BLOB then?


signature.asc
Description: PGP signature

src.conf: CFLAGS/COPTFLAGS inconsistency

2014-09-19 Thread O. Hartmann

man make.conf states, that COPTFLAGS is used for building/compiling the kernel
(exclusively). The question arises: are kernel modules NOT kernel or are they 
kernel?

The problem I face is that with optimization level -O3 loader.efi gets 
miscompiled and a
UEFI laptop stops/reject booting. To avoid other interference, I defined 
COPTFLAGS
in /etc/src.conf accordingly, but leave CFLAGS?=-O3 in /etc/make.conf for 
compilation of
regular ports and the rest of the OS.

I can observe that with CFLAGS set, either in make.conf, or src.conf or mutual 
exclusive,
the CFLAGS is ALWAYS incorporated when kernel stuff like modules and even the 
loader.efi
is built! I consider this inconsitent, since loader.efi is definitely kernel 
related
stuff as well as modules.

It seems to me that it s not possible to separate cleanly CFLAGS and COPTFLAGS 
for
userland/ports and kernel-only related compilations as described in the man 
page. 


signature.asc
Description: PGP signature

Re: CURRENT: EFI boot failure

2014-09-19 Thread O. Hartmann

Am Wed, 17 Sep 2014 01:25:07 +0300
Andriy Gapon a...@freebsd.org schrieb:

 On 17/09/2014 00:32, Ed Maste wrote:
  On 16 September 2014 17:03, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
  In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? 
  What is the
  difference? Is the efi partition FAT?
  
  An EFI system partition (ESP) is a FAT-formatted partition with a
  specific GPT or MBR identifier and file system hierarchy; EFI firmware
  will try to load /EFI/BOOT/BOOTX64.EFI from the ESP.
 
 A very useful read about how EFI boot process works and how different OSes 
 boot
 on top of it:
 http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html
 
  boot1.efi is an EFI application - that is, a PECOFF format binary.  It
  searches for a UFS filesystem and loads loader.efi from that.  It is
  intended to simplify the UEFI boot process, so that loader.efi, the
  .4th files, loader.conf etc. do not all need to be installed in the
  ESP.
  
  boot1.efifat is a FAT filesystem image that contains a copy of
  boot1.efi as /EFI/BOOT/BOOTX64.EFI.  It exists so that the installer
  can treat it as opaque bootcode, like other boot schemes.  It's
  certainly possible to create a partition, use newfs_msdos to format
  it, and copy in boot1.efi instead.
  
  It is one disk, dedicated to FreeBSD (a laptop disk). Is there any 
  documentation
  readable for non-developer for that matter? I'm curious about how EFI 
  works on
  FreeBSD.
  
  Better user-facing documentation is in progress; for now the best
  source is probably the wik.
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
  
 
 

The problem I reported about in the first place is triggered by a faulty 
loader.efi that
arises, when optimisation level is -O3. -O2 works fine.

I also realized that there is a kind of inconsistency in how COPTFLAGS and 
CFLAGS are
handled in reality compared to that what the manpage of make.conf states. 
Setting
COPTFLAGS=-O2 for compiling kernel stuff only ALWAYS incorporates CFLAGS, which 
is set to
CFLAGS=-O3 in make.conf in my case. loader.efi is, in my opinion, kernel stuff 
only as
well as kernel modules, which also gets compiled with CFLAGS.


signature.asc
Description: PGP signature

x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

2014-09-19 Thread O. Hartmann

nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD 
11.0-CURRENT
#2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge E540 
laptop with
CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and dedicated nVidia 
GT 740M
(Optimus) working correctly.

The systems boots FreeBSD off via UEFI.

First of all: I tried versions 340.24, 340.32 and Beta 343.13 all with the very 
same
results.

Symptoms:

a) Loading kernel module nvidia via /boot/load.conf freezes the system after 
the
UEFI/EFI loader message shows up. Loading the kernel module vi kld_load=
in /etc/rc.conf[.local] works so far regarding loading and booting the kernel.

b) No display socket is recognized by the nvidia driver resulting in a blank 
vt() screen
after X has been started. I tried many different configurations, but at the end 
I suspect
that nVidia's Optimus technology may be the culprit.

The documentation of nVidia's driver for FreeBSD states that after the Xserver 
has
started it logs in Xorg.0.log (or whatever display number is used) the 
available display
sockets like (taken from the documents):

(--) NVIDIA(0): Valid display device(s) on Quadro 6000 at PCI:10:0:0
(--) NVIDIA(0): CRT-0
(--) NVIDIA(0): CRT-1
(--) NVIDIA(0): DELL U2410 (DFP-0) (connected)
(--) NVIDIA(0): NEC LCD1980SXi (DFP-1) (connected)

Nothing that similar shows up in my environment, but this:

[...]
[58.656] (--) PCI:*(0:0:2:0) 8086:0416:17aa:502a rev 6, Mem @ 
0xf100/4194304,
0xe000/268435456, I/O @ 0x6000/64, BIOS @ 0x/65536
[58.659] (--) PCI: (0:1:0:0) 10de:1292:17aa:502a rev 161, Mem @ 
0xf000/16777216,
0xc000/268435456, 0xd000/33554432, I/O @ 0x5000/128
[58.662] (II) extmod will be loaded. This was enabled by default and also 
specified
in the config file.
[58.662] (II) dbe will be loaded. This was enabled by default and also 
specified in
the config file.
[...]
[60.055] (**) NVIDIA(0): Enabling 2D acceleration
[60.485] (II) NVIDIA(0): NVIDIA GPU GeForce GT 740M (GK208) at PCI:1:0:0 
(GPU-0)
[60.486] (--) NVIDIA(0): Memory: 2097152 kBytes
[60.486] (--) NVIDIA(0): VideoBIOS: 80.28.25.00.27
[60.486] (II) NVIDIA(0): Detected PCI Express Link width: 8X
[60.486] (--) NVIDIA(0): Valid display device(s) on GeForce GT 740M at 
PCI:1:0:0
[60.487] (--) NVIDIA(0): none
[60.487] (II) NVIDIA(0): Validated MetaModes:
[60.487] (II) NVIDIA(0): NULL
[60.487] (II) NVIDIA(0): Virtual screen size determined to be 640 x 480
[60.488] (WW) NVIDIA(0): Unable to get display device for DPI computation.
[60.488] (==) NVIDIA(0): DPI set to (75, 75); computed from built-in default
[60.488] (--) Depth 24 pixmap format is 32 bpp
[60.489] (II) NVIDIA: Reserving 3072.00 MB of virtual memory for indirect 
memory
[60.489] (II) NVIDIA: access.
[60.492] (II) NVIDIA(0): Setting mode NULL
[60.493] (EE) NVIDIA(0): Failed to initiate mode change.
[60.493] (EE) NVIDIA(0): Failed to complete mode change
[60.553] (II) NVIDIA(0): Built-in logo is bigger than the screen.
[60.573] (II) Loading extension NV-GLX
[...]

Confusing is that in the lines
[58.656] (--) PCI:*(0:0:2:0) 8086:0416:17aa:502a rev 6, Mem @ 
0xf100/4194304,
0xe000/268435456, I/O @ 0x6000/64, BIOS @ 0x/65536
[58.659] (--) PCI: (0:1:0:0) 10de:1292:17aa:502a rev 161, Mem @ 
0xf000/16777216,
0xc000/268435456, 0xd000/33554432, I/O @ 0x5000/128

both, the Intel iGPU HD4600 (PCI:*(0:0:2:0)) and the nVidia dedicated GPU GT 
740M (PCI: (0:1:0:0)) show up.

The more scaring part is then (--) NVIDIA(0): Valid display device(s):

No display device is shown although the notebook has a built-in display, a 
DisplayPort
port as well as a VGA port. On all nVidia dedicated graphics boards I use on 
diffrent
other machines with the very same driver EVERY possible connector/socket shows 
up.

The laptop has EFI/UEFI

EFI Version: 2.31
EFI Firmware: Lenovo (re. 05648)

The problem is present no matter whether the drm2 and i915kms kernel moules are 
loaded or
not.

What is wrong here? Any chance to get the nVidia GPU to work? I use at the 
moment
xf86-video-scfb which is a pain in the ass and absolutely not usable, even with 
a faster
CPU. Under average load the whole laptop screen is like a slide show.

Please CC me.

Thanks in advance,
O. Hartmann


signature.asc
Description: PGP signature

Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI

Am Tue, 16 Sep 2014 08:40:25 -0700
Adrian Chadd adr...@freebsd.org schrieb:

 Ah, jumbo frames. Maybe you got lucky and some ethernet drivers
 default to accepting larger frames even if the MTU is 1500.
 
 
 -a


After all, I managed to get the NIC up and running. But the culprit is that I 
have to
take the NIC down and then up to make it working once the system has bootet. 
That is
annoying. Lucckily, I can provide better informations since the box s now 
attached to the
network. Here we go:

LAN:
re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10 hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class  = network
subclass   = ethernet
bar   [10] = type I/O Port, range 32, base 0x3000, size 256, enabled
bar   [18] = type Memory, range 64, base 0xf1d04000, size 4096, enabled
bar   [20] = type Memory, range 64, base 0xf1d0, size 16384, enabled
cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
cap 05[50] = MSI supports 1 message, 64 bit 
cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1)
 speed 2.5(2.5) ASPM disabled(L0s/L1)
cap 11[b0] = MSI-X supports 4 messages, enabled
 Table in map 0x20[0x0], PBA in map 0x20[0x800]
cap 03[d0] = VPD
ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1 0100684ce000
ecap 0018[170] = LTR 1
ecap 001e[178] = unknown 1
  PCI-e errors = Correctable Error Detected
 Corrected = Receiver Error


WiFi (supposed to be Intel ):
none2@pci0:5:0:0:   class=0x028000 card=0x42628086 chip=0x08b28086 rev=0x73 
hdr=0x00
vendor = 'Intel Corporation'
class  = network
bar   [10] = type Memory, range 64, base 0xf1c0, size 8192, enabled
cap 01[c8] = powerspec 3  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit 
cap 10[40] = PCI-Express 2 endpoint max data 128(128) FLR link x1(x1)
 speed 2.5(2.5) ASPM L1(L0s/L1)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 ac7ba1a06fd6
ecap 0018[14c] = LTR 1
ecap 000b[154] = Vendor 1 ID 51966

The WiFi NIC isn't recognized by any driver in CURRENT (11.0-CURRENT #5 
r271728: Thu Sep
18 01:18:25 CEST 2014 amd64)

Maybe this is of help.

Oliver


signature.asc
Description: PGP signature

Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI

Am Thu, 18 Sep 2014 10:17:08 +0200
Guido Falsi m...@madpilot.net schrieb:

 On 09/18/14 09:58, O. Hartmann wrote:
  Am Tue, 16 Sep 2014 08:40:25 -0700
  Adrian Chadd adr...@freebsd.org schrieb:
  
  Ah, jumbo frames. Maybe you got lucky and some ethernet drivers
  default to accepting larger frames even if the MTU is 1500.
 
 
  -a
  
  
  After all, I managed to get the NIC up and running. But the culprit is that 
  I have to
  take the NIC down and then up to make it working once the system has 
  bootet. That is
  annoying. Lucckily, I can provide better informations since the box s now 
  attached to
  the network. Here we go:
  
 
 I have a similar situation with my nick on a tower system.
 
 I need to change at least one flag on the card to have it working, I can
 also just set the flag to the value it already has.
 
 I'm using a small startup script which actually does this:
 
 start_cmd=ifconfig ${refix_if} tso
 
 
  LAN:
  re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10 
  hdr=0x00
  vendor = 'Realtek Semiconductor Co., Ltd.'
  device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
  class  = network
  subclass   = ethernet
  bar   [10] = type I/O Port, range 32, base 0x3000, size 256, enabled
  bar   [18] = type Memory, range 64, base 0xf1d04000, size 4096, enabled
  bar   [20] = type Memory, range 64, base 0xf1d0, size 16384, enabled
  cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
  cap 05[50] = MSI supports 1 message, 64 bit 
  cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1)
   speed 2.5(2.5) ASPM disabled(L0s/L1)
  cap 11[b0] = MSI-X supports 4 messages, enabled
   Table in map 0x20[0x0], PBA in map 0x20[0x800]
  cap 03[d0] = VPD
  ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
  ecap 0002[140] = VC 1 max VC0
  ecap 0003[160] = Serial 1 0100684ce000
  ecap 0018[170] = LTR 1
  ecap 001e[178] = unknown 1
PCI-e errors = Correctable Error Detected
   Corrected = Receiver Error
 
 
 re0@pci0:3:0:0: class=0x02 card=0x11c01734 chip=0x816810ec rev=0x07
 hdr=0x00
 vendor = 'Realtek Semiconductor Co., Ltd.'
 device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
 class  = network
 subclass   = ethernet
 bar   [10] = type I/O Port, range 32, base 0xd000, size 256, enabled
 bar   [18] = type Prefetchable Memory, range 64, base 0xf2104000,
 size 4096, enabled
 bar   [20] = type Prefetchable Memory, range 64, base 0xf210,
 size 16384, enabled
 cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
 cap 05[50] = MSI supports 1 message, 64 bit
 cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1)
  speed 2.5(2.5) ASPM disabled(L0s/L1)
 cap 11[b0] = MSI-X supports 4 messages, enabled
  Table in map 0x20[0x0], PBA in map 0x20[0x800]
 cap 03[d0] = VPD
 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
 ecap 0002[140] = VC 1 max VC0
 ecap 0003[160] = Serial 1 01000401
   PCI-e errors = Correctable Error Detected
  Unsupported Request Detected
  Corrected = Advisory Non-Fatal Error
 
 it's similar hardware, same chip, different revision. I already reported
 this on net@ but no patch could really solve the issue.
 

Hello.

Well, it seems the same here with taht specific NIC. Changing ANYTHING, even 
already
enabled features, or bringing the NIC down and then up seem to solve this 
problem.

I guess, I file a PR to make this issue memorized.

Regards,

Oliver


signature.asc
Description: PGP signature

UEFI/CURRENT: vt() and nVidia BLOB: not working on nVidia GT 740M

Running FreeBSD 11.0-CURRENT #5 r271728: Thu Sep 18 01:18:25 CEST 2014 amd64 on 
a Lenovo
ThinkPad Edge E540 laptop with built-in nVidida GT 740M GPU (NV208M) doesn't 
bring up X11
even with most recent nVidia  BLOB 343.13.

The system has been installed from a most recent FBSD CURRENT USB drive image 
and uses
UEFI and newcons/vt(). IN UEFI Firmware, the primary GPU selected is the nVidia 
GT 740M
in favour of the Intel iGPU HD4600 of the Haswell CPU.

While the system works well with console only after UEFI boot, I can not start 
X11 having
driver nvidia enabled, the portion in xorg.conf reflecting this is as follows:

Section Device
Identifier  Card0
VendorName  nVidia
BoardName   GT740M
Driver  nvidia
BusID   PCI:1:0:0
EndSection

When starting X, the screen goes blank and black with a stuck mousepointer 
showing up and
a green (colour defined in my console) carret showing in the left hand upper 
corner of the
screen - and nothing happens anymore.

Using driver nv from the regular xorg installation from the ports (having set 
WITH_NEW_XORG=  YES
WITH_KMS=   YES
WITH_GALLIUM=   YES
in /etc/make.conf) fails with the error, that the driver doesn't recognises the 
GPU type.

The only working solution is the very slow and unusable 
x11-drivers/xf86-video-scfb
unaccelerated software framebuffer.

I'd like to use the accelerated nVidia GPU with the BLOB as I do on all other 
FreeBSD
boxes I use (systems still without UEFI and graphical vt()).

What am I doing wrong here?

Has someone successfully bootet FBSD CURRENT via EUFI and nVidia accelerated 
GPU via
nVidia's BLOB?

Thanks in advance,

Oliver


signature.asc
Description: PGP signature

Re: UEFI/CURRENT: vt() and nVidia BLOB: not working on nVidia GT 740M

Am Thu, 18 Sep 2014 07:19:45 -0700
Nathan Whitehorn nwhiteh...@freebsd.org schrieb:

 
 On 09/18/14 04:18, O. Hartmann wrote:
  Running FreeBSD 11.0-CURRENT #5 r271728: Thu Sep 18 01:18:25 CEST 2014 
  amd64 on a
  Lenovo ThinkPad Edge E540 laptop with built-in nVidida GT 740M GPU (NV208M) 
  doesn't
  bring up X11 even with most recent nVidia  BLOB 343.13.
 
  The system has been installed from a most recent FBSD CURRENT USB drive 
  image and uses
  UEFI and newcons/vt(). IN UEFI Firmware, the primary GPU selected is the 
  nVidia GT
  740M in favour of the Intel iGPU HD4600 of the Haswell CPU.
 
  While the system works well with console only after UEFI boot, I can not 
  start X11
  having driver nvidia enabled, the portion in xorg.conf reflecting this is 
  as
  follows:
 
  Section Device
   Identifier  Card0
   VendorName  nVidia
   BoardName   GT740M
   Driver  nvidia
   BusID   PCI:1:0:0
  EndSection
 
  When starting X, the screen goes blank and black with a stuck mousepointer 
  showing up
  and a green (colour defined in my console) carret showing in the left hand 
  upper
  corner of the screen - and nothing happens anymore.
 
  Using driver nv from the regular xorg installation from the ports (having 
  set
  WITH_NEW_XORG=  YES
  WITH_KMS=   YES
  WITH_GALLIUM=   YES
  in /etc/make.conf) fails with the error, that the driver doesn't recognises 
  the GPU
  type.
 
  The only working solution is the very slow and unusable 
  x11-drivers/xf86-video-scfb
  unaccelerated software framebuffer.
 
  I'd like to use the accelerated nVidia GPU with the BLOB as I do on all 
  other FreeBSD
  boxes I use (systems still without UEFI and graphical vt()).
 
  What am I doing wrong here?
 
  Has someone successfully bootet FBSD CURRENT via EUFI and nVidia 
  accelerated GPU via
  nVidia's BLOB?
 
  Thanks in advance,
 
  Oliver
 
 I'm using UEFI and the blob every day without issue. However, that is 
 with an add-in card. It's possible that X11 or the nVidia driver is 
 trying to reinitialize the card through the (potentially non-existant) 
 video BIOS, which fails. Is there any option like NoInt10 you can turn 
 on in X configuration?
 -Nathan


I tried

Option NoInt10
Option PrimaryInt

both in all combinations possible without any success. It is good to hear that 
at least
one successful run of the BLOB with UEFI/vt can be reported, so the problem 
might be of a
minor issue - hopefully.

The GPU is a dedicated PCIe GPU for the notebook, combined with the HD4600 
which can be
used via nVidia's Optimus switching - if software supports it. In the UEFI, I 
selected
the nVidia dedicated GPU as the primary one.

The way the dead screen shows up reminds me of a dead end screen: the 
left-hand top
carret and the console's mousepointer (at the position it was on the console) 
look like
as the whole output is now delegated towards another output socket. The 
keyboard works
surprisingly NOT as expected, since I have to switch this Lenovo FN key for 
Ctrl - which
then allows me to switch back to the console and terminate the X server or xdm.

I need to figure out what name's the sockets have (on the Dell Latitude I have, 
they are
called DPS-0 to DPS-2 for the internal display, the HDMI and the DisplayPort 
socket and
VGA-0 for the VGA socket).

Will report back ...
Oliver


signature.asc
Description: PGP signature

Re: CURRENT: EFI boot failure

Am Tue, 16 Sep 2014 02:05:41 +0200
O. Hartmann ohart...@zedat.fu-berlin.de schrieb:

 
 Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works for 
 UEFI fine.
 After I updated the sources to  r271649, recompiled world and kernel (as well 
 as
 installed), now I get stuck with the screen message:
 
  FreeBSD EFI boot block
Loader path: /boot/loader.efi
 
 and nothing happens. After a couple of minutes, the system reboots.
 
 What happened and how can this problem be solved?


after today's make world (revision 271800) and two days of normal operation, 
I run into
the same situation as described above! This is more than annoying! The screen 
show simply


 FreeBSD EFI boot block
   Loader path: /boot/loader.efi

and nothing happens forever. Usually, the loader/console shows up. This time 
the system
gets stuck as I reported earlier.

I can not afford another two days of installing the laptop again. How can I get 
rid of
this immature EFI and run the system in the traditional way? It seems two 
immature
systems meet each other, vt() and EFI and this ends up in a desaster.

What is the fallback procedure? How to save the system and circumvent this 
problem? Is
there a way to interrupt the boot process and drop out into some kind of 
emergency
screen/console?

BTW, I temporarily fixed this issu by copying the USB drive image's loader.efi 
into boot.
This seems to be a bug in the compiler/compiling loader.efi.


signature.asc
Description: PGP signature

Re: CURRENT: EFI boot failure

2014-09-17 Thread O. Hartmann

Am Tue, 16 Sep 2014 15:54:31 -0700
Nathan Whitehorn nwhiteh...@freebsd.org schrieb:

 
 On 09/16/14 14:50, O. Hartmann wrote:
  Am Tue, 16 Sep 2014 00:09:01 -0700
  Nathan Whitehorn nwhiteh...@freebsd.org schrieb:
 
  On 09/15/14 22:51, O. Hartmann wrote:
  Am Mon, 15 Sep 2014 17:39:26 -0700
  Nathan Whitehorn nwhiteh...@freebsd.org schrieb:
 
  On 09/15/14 17:36, Allan Jude wrote:
  On 2014-09-15 20:05, O. Hartmann wrote:
  Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop 
  works for UEFI
  fine. After I updated the sources to  r271649, recompiled world and 
  kernel (as
  well as installed), now I get stuck with the screen message:
 
  FreeBSD EFI boot block
Loader path: /boot/loader.efi
 
  and nothing happens. After a couple of minutes, the system reboots.
 
  What happened and how can this problem be solved?
 
  You might need to update the boot1.efi file on the UEFI partition (small
  FAT partition on the disk)
 
  I am not sure how 'in sync' boot1.efi (on the fat partiton) and
  loader.efi have to be.
 
  https://wiki.freebsd.org/UEFI
 
  boot1.efi is designed never to need updating. (It also hasn't changed
  since April)
  -Nathan
  But it has changed bytesize when I recompiled world with recent sources 
  compared to
  the boot.efi size from the USB image I installed from (revision see 
  above).
  Probably compiler updates or something? I really wouldn't worry about it
  too much. I'd worry more about loader, since we know boot1 could use the
  console but loader doesn't show up.
 
  How to update bootcode on UEFI layout? I created a GPT partition with 
  type efi (1
  GB) as well as a 512KB partition typed freebsd-boot.
  How did you set it up in the first place? If you have a FreeBSD-only
  system partition (like the installer sets up), you just dd
  /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you
  copy /boot/boot1.efi to somewhere your boot manager can find it.
 
  I'm new to EFI and the way the notebook now behaves is really strange. 
  While the USB
  drive image used to boot with new console enabled, it now boots again 
  with the old
  console and 800x640 resolution. This might indicate some minor but very 
  effective
  mistake I made.
 
  The EFI boot block finds the first UFS partition -- on any disk -- and
  tries to boot from it. If you have multiple FreeBSD disks connected,
  that will very likely result in madness.
  -Nathan
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
  After I managed to install the OS and updated to the most recent world, it 
  took two
  days to have all the installations prepared. Now I'm about the configure 
  X11 and run
  into another very annoying situation.
 
  The Laptop is a Lenovo ThinkPad Edge E540 equipted with the following 
  CPU/iGPU and
  dedicated GPU:
 
  CPU Intel i5-4200M (Haswell) at 2.5 GHz with iGPU Intel HD Graphics 4600
 
  GPU: nVidia GT 740M mobile GPU.
 
  EFI Version 2.31
  EFI Firmware: Lenovo (rev. 05648)
 
  In the Firmware/EFI/BIOS the primary GPU is selected to be the nVidia GT 
  740M. Boot is
  EFI only, no CSM support. With CSM support enabled a VGA screen with 
  640x400 pixel
  shows up. Non UEFI options doesn't boot this system at all!
 
  Any attempt to bring up the nVidia GPU (starting X for testing) ends up in 
  a blank
  screen, stuck mousepointer, no keyboard. I even can not switch to another 
  console!
  When X server started the first time on tty9, I can switch to another 
  console. But the
  moment I switch back to ttyv9 everything is frozen and as described above.
 
 Try xf86-video-scfb instead?
 
  When the system boots, I do not see a loader! Where is the loader I'm used 
  to see
  when I have the chance to switch to single user mode, console or switch off 
  ACPI?
 
 There is no beastie menu for UEFI, and will not be, since it UEFI's 
 terminal emulation does not provide the required features. You can boot 
 single user from the loader command line, however, with boot -s, for 
 example. The interface is identical to what you get if you choose 
 Loader prompt in the usual menu.

Good to know.

 
  Because I need X11 up (and it should be running on the nVidia GPU for 
  performance
  reasons), I tried to get back to the legacy sc console in textmode since 
  I read
  about several issues and immature vt() system, so I put those lines in
  the /boot/loader.conf:
 
  hw.vga.textmode=1
  hw.vty=sc
 
  (tried also hw.vty=vt).
 
  But with either of those lines in the loader thing get more annoying and 
  nasty: The
  system doesn't show even a console, it is stuck with this sparse EFI boot 
  message,
  last lines are
 
  dimensions  x 
  stride 
  masks 0xfff [...]
 
  and the rest of the screen is blank. System remains unusable, the HDD is 
  working and
  obviously

Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI

Am Mon, 15 Sep 2014 18:25:34 -0700
Adrian Chadd adr...@freebsd.org schrieb:

 Hi,
 
 Try updating to the latest -HEAD. It at least makes dhclient behave better.
 
 
 -a
 
 
 On 15 September 2014 18:19, Kevin Oberman rkober...@gmail.com wrote:
  On Mon, Sep 15, 2014 at 2:38 PM, O. Hartmann ohart...@zedat.fu-berlin.de
  wrote:
 
 
  Trying to install and run FreeBSD 11.0-CURRENT
  (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Lenovo
  E540 notebook
  fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The NIC
  shows up as
  active and with carrier when issuing ifconfig re0.
 
  From a desktop machine, I tried to ping the system in question and I get a
  result with
  missing packets:
 
  ping: sendto: Host is down
  ping: sendto: Host is down
  ping: sendto: Host is down
  64 bytes from 192.168.0.130: icmp_seq=26 ttl=64 time=0.114 ms
  64 bytes from 192.168.0.130: icmp_seq=41 ttl=64 time=0.130 ms
  64 bytes from 192.168.0.130: icmp_seq=60 ttl=64 time=0.119 ms
  64 bytes from 192.168.0.130: icmp_seq=80 ttl=64 time=0.119 ms
  64 bytes from 192.168.0.130: icmp_seq=100 ttl=64 time=0.105 ms
  64 bytes from 192.168.0.130: icmp_seq=116 ttl=64 time=0.135 ms
  64 bytes from 192.168.0.130: icmp_seq=136 ttl=64 time=0.091 ms
 
  DHCP configuration fails, since no DHCP offer is discovered.
 
  I swapped the switches, the cabling and I had always the same results. I
  used another
  Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) and
  that system
  gets DHCP offer and is online.
 
  Since the notebook is brandnew, the last thing I'll suspect is a
  defective NIC, so I'll
  ask whether this phenomenon is known - or, if not, the results
  definititely would
  indicate a broken NIC.
 
  Another point is the WiFI adaptor. This notebook is supposed to have a
  WiFi NIC, but it
  doesn't get revealed by FreeBSD (I tried iwn/iwi without success).
 
  pciconf output below, sorry for the messy shape, it is a copy-and-paste
  from that immature
  vt() terminal.
 
  Has anyone successfully installed that type of Notebook with FreeBSD
  CURRENT using NIC
  and Wifi?
 
  Please CC me.
 
 
  Regards
  oh
 
 
  [...]
 
  none1@pci0:3:0:0:   class=0xff card=0x502817aa chip=0x522710ec
  rev=0x01 hdr=0x00
 
 
  vendor = 'Realtek Semiconductor Co., Ltd.'
 
 
  bar   [10] = type Memory, range 32, base 0xf1e0, size 4096, enabled
 
 
  cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
 
 
  cap 05[50] = MSI supports 1 message, 64 bit
 
 
  cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1)
 
 
   speed 2.5(2.5) ASPM L0s/L1(L0s/L1)
 
 
  ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected
 
 
  ecap 0003[140] = Serial 1 0001004ce000
 
 
  re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10
  hdr=0x00
 
 
  subclass   = ethernet
 
 
  cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current
  D0
  di sabled(L0s/L1)
 
 
  cap 11[b0] = MSI-X supports 4 messages, enabled
 
  ecap 0001[100] = AER 2 0 fatal 0 non-fatal 4 corrected
 
 
 
  ecap 001e[178] = unknown 1
 
 
  class  = network
 
 
  cap 05[d0] = MSI supports 1 message, 64 bit
 
 
  ecap 0003[140] = Serial 1 ac7ba1a06fd6
 
 
  I can't comment on the WiFi, I have little Asus box using an 8111/8168B and
  it works fine with the driver in 10.1-BETA. The driver in 10.0 recognizes
  the device, but did not work. I do notice that your NIC has a rev of 0x10
  while mine is 0x0c.
  --
  Kevin Oberman, Network Engineer, Retired


In my local network (the laptop is working/getting installed in) I use jumbo 
frames on
several server system including the gateway (also FBSD CURRENT).

After I manually set mtu  1500 (in my case: mtu 6121) the NIC worked as 
expected. My
lab's Dell Latitude E6510 laptop (em0) works without setting explicit jumbo 
frames. This
is a kind of weird ...

Thanks for your patience.

Oliver




signature.asc
Description: PGP signature

zpool: multiple IDs, CURRENT drops all pools after reboot

On of my backup drives dedicated to a ZPOOL is faulting and showing up multiple 
ID. The
only working ID is id: 257822624560506537.

FreeBSD CURRENT with three ZFS disks and only 4GB of RAM is very flaky 
regarding this
issue: today, tow times the whole poolset vanishes after a reboot. Giving the 
box 8 GB
total and rebooting doens't show the problem, it gets more frequent when 
reducing the RAM
to 4GB (FreeBSD 11.0-CURRENT #2 r271684: Tue Sep 16 20:41:47 CEST 2014). This 
is a bit
spooky.

Below the faulted harddrive. I guess the drive/pool below shown triggers 
somehow the loss
of all other pools (I have to import the other pools, which do not have any 
defects, but
they they drop out after a reboot and vanish).

Is there a way getting rid of the faulty IDs without destroying the pool?

Regards,

Oliver 

 root@thor: [/etc] zpool import
   pool: BACKUP00
 id: 9337833315545958689
  state: FAULTED
 status: One or more devices contains corrupted data.
 action: The pool cannot be imported due to damaged devices or data.
The pool may be active on another system, but can be imported using
the '-f' flag.
   see: http://illumos.org/msg/ZFS-8000-5E
 config:

BACKUP00   FAULTED  corrupted data
  8544670861382329237  UNAVAIL  corrupted data

   pool: BACKUP00
 id: 257822624560506537
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

BACKUP00ONLINE
  ada3p1ONLINE


signature.asc
Description: PGP signature

Re: CURRENT: EFI boot failure

Am Tue, 16 Sep 2014 00:09:01 -0700
Nathan Whitehorn nwhiteh...@freebsd.org schrieb:

 
 On 09/15/14 22:51, O. Hartmann wrote:
  Am Mon, 15 Sep 2014 17:39:26 -0700
  Nathan Whitehorn nwhiteh...@freebsd.org schrieb:
 
  On 09/15/14 17:36, Allan Jude wrote:
  On 2014-09-15 20:05, O. Hartmann wrote:
  Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works 
  for UEFI
  fine. After I updated the sources to  r271649, recompiled world and 
  kernel (as well
  as installed), now I get stuck with the screen message:
 
  FreeBSD EFI boot block
   Loader path: /boot/loader.efi
 
  and nothing happens. After a couple of minutes, the system reboots.
 
  What happened and how can this problem be solved?
 
  You might need to update the boot1.efi file on the UEFI partition (small
  FAT partition on the disk)
 
  I am not sure how 'in sync' boot1.efi (on the fat partiton) and
  loader.efi have to be.
 
  https://wiki.freebsd.org/UEFI
 
  boot1.efi is designed never to need updating. (It also hasn't changed
  since April)
  -Nathan
 
  But it has changed bytesize when I recompiled world with recent sources 
  compared to
  the boot.efi size from the USB image I installed from (revision see above).
 
 Probably compiler updates or something? I really wouldn't worry about it 
 too much. I'd worry more about loader, since we know boot1 could use the 
 console but loader doesn't show up.

Well, I have to worry about because the system is stuck and completely unusable.

I installed the system from the very same USB drive image as mentioned above 
again. Then,
after the newtork issue has been fixed, I was able to update sources and built 
world. As
long as I do not attempt to use to use X, everything is fine.

 
  How to update bootcode on UEFI layout? I created a GPT partition with type 
  efi (1 GB)
  as well as a 512KB partition typed freebsd-boot.
 
 How did you set it up in the first place? If you have a FreeBSD-only 
 system partition (like the installer sets up), you just dd 
 /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you 
 copy /boot/boot1.efi to somewhere your boot manager can find it.

The setup was plain and vanilla. I used the installer of the USB image (see 
above).
Creating GPT partition scheme and two partitions of type efi and 
freebsd-boot, first
1MB, latter 512KB. All other partitions are freebsd-ufs, exept freebsd-swap.

In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What is 
the
difference? Is the efi partition FAT?

 
  I'm new to EFI and the way the notebook now behaves is really strange. 
  While the USB
  drive image used to boot with new console enabled, it now boots again with 
  the old
  console and 800x640 resolution. This might indicate some minor but very 
  effective
  mistake I made.
 
 
 The EFI boot block finds the first UFS partition -- on any disk -- and 
 tries to boot from it. If you have multiple FreeBSD disks connected, 
 that will very likely result in madness.
 -Nathan

It is one disk, dedicated to FreeBSD (a laptop disk). Is there any 
documentation readable
for non-developer for that matter? I'm curious about how EFI works on FreeBSD.

Oliver


signature.asc
Description: PGP signature

Re: CURRENT: EFI boot failure

Am Mon, 15 Sep 2014 20:36:23 -0400
Allan Jude allanj...@freebsd.org schrieb:

 On 2014-09-15 20:05, O. Hartmann wrote:
  
  Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works 
  for UEFI
  fine. After I updated the sources to  r271649, recompiled world and kernel 
  (as well as
  installed), now I get stuck with the screen message:
  
  FreeBSD EFI boot block
 Loader path: /boot/loader.efi
  
  and nothing happens. After a couple of minutes, the system reboots.
  
  What happened and how can this problem be solved?
  
 
 You might need to update the boot1.efi file on the UEFI partition (small
 FAT partition on the disk)
 
 I am not sure how 'in sync' boot1.efi (on the fat partiton) and
 loader.efi have to be.
 
 https://wiki.freebsd.org/UEFI
 

Is it boot1.efi or is it boot1.efifat?


signature.asc
Description: PGP signature

Re: CURRENT: EFI boot failure

Am Tue, 16 Sep 2014 00:09:01 -0700
Nathan Whitehorn nwhiteh...@freebsd.org schrieb:

 
 On 09/15/14 22:51, O. Hartmann wrote:
  Am Mon, 15 Sep 2014 17:39:26 -0700
  Nathan Whitehorn nwhiteh...@freebsd.org schrieb:
 
  On 09/15/14 17:36, Allan Jude wrote:
  On 2014-09-15 20:05, O. Hartmann wrote:
  Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works 
  for UEFI
  fine. After I updated the sources to  r271649, recompiled world and 
  kernel (as well
  as installed), now I get stuck with the screen message:
 
  FreeBSD EFI boot block
   Loader path: /boot/loader.efi
 
  and nothing happens. After a couple of minutes, the system reboots.
 
  What happened and how can this problem be solved?
 
  You might need to update the boot1.efi file on the UEFI partition (small
  FAT partition on the disk)
 
  I am not sure how 'in sync' boot1.efi (on the fat partiton) and
  loader.efi have to be.
 
  https://wiki.freebsd.org/UEFI
 
  boot1.efi is designed never to need updating. (It also hasn't changed
  since April)
  -Nathan
 
  But it has changed bytesize when I recompiled world with recent sources 
  compared to
  the boot.efi size from the USB image I installed from (revision see above).
 
 Probably compiler updates or something? I really wouldn't worry about it 
 too much. I'd worry more about loader, since we know boot1 could use the 
 console but loader doesn't show up.
 
  How to update bootcode on UEFI layout? I created a GPT partition with type 
  efi (1 GB)
  as well as a 512KB partition typed freebsd-boot.
 
 How did you set it up in the first place? If you have a FreeBSD-only 
 system partition (like the installer sets up), you just dd 
 /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you 
 copy /boot/boot1.efi to somewhere your boot manager can find it.
 
  I'm new to EFI and the way the notebook now behaves is really strange. 
  While the USB
  drive image used to boot with new console enabled, it now boots again with 
  the old
  console and 800x640 resolution. This might indicate some minor but very 
  effective
  mistake I made.
 
 
 The EFI boot block finds the first UFS partition -- on any disk -- and 
 tries to boot from it. If you have multiple FreeBSD disks connected, 
 that will very likely result in madness.
 -Nathan
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

After I managed to install the OS and updated to the most recent world, it took 
two days
to have all the installations prepared. Now I'm about the configure X11 and run 
into
another very annoying situation.

The Laptop is a Lenovo ThinkPad Edge E540 equipted with the following CPU/iGPU 
and
dedicated GPU:

CPU Intel i5-4200M (Haswell) at 2.5 GHz with iGPU Intel HD Graphics 4600

GPU: nVidia GT 740M mobile GPU.

EFI Version 2.31
EFI Firmware: Lenovo (rev. 05648)

In the Firmware/EFI/BIOS the primary GPU is selected to be the nVidia GT 740M. 
Boot is
EFI only, no CSM support. With CSM support enabled a VGA screen with 640x400 
pixel shows
up. Non UEFI options doesn't boot this system at all!

Any attempt to bring up the nVidia GPU (starting X for testing) ends up in a 
blank
screen, stuck mousepointer, no keyboard. I even can not switch to another 
console!
When X server started the first time on tty9, I can switch to another console. 
But the
moment I switch back to ttyv9 everything is frozen and as described above.

When the system boots, I do not see a loader! Where is the loader I'm used to 
see when I
have the chance to switch to single user mode, console or switch off ACPI?

Because I need X11 up (and it should be running on the nVidia GPU for 
performance
reasons), I tried to get back to the legacy sc console in textmode since I 
read about
several issues and immature vt() system, so I put those lines in the 
/boot/loader.conf:

hw.vga.textmode=1
hw.vty=sc

(tried also hw.vty=vt).

But with either of those lines in the loader thing get more annoying and nasty: 
The
system doesn't show even a console, it is stuck with this sparse EFI boot 
message, last
lines are

dimensions  x 
stride 
masks 0xfff [...]

and the rest of the screen is blank. System remains unusable, the HDD is 
working and
obviously booting the system but incapable of presenting a screen. When booting 
the USB
drive image, this initial EFI message gets overwritten (no screen blanking, the 
kernel
messages starts writing over this message like in the first days of computers 
...). In
the case described above that doesn't happen at all.

After I deleted.commented out the lines 

hw.vga.textmode=1
hw.vty=sc

in loader.conf the system is booting again - and clears the initial EFI 
messages before
dumping the screen with kernel messages, as expected.

Well, at the end, it seems I sit in front of two days useless labor, new 
hardware

Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI

Am Tue, 16 Sep 2014 08:40:25 -0700
Adrian Chadd adr...@freebsd.org schrieb:

 Ah, jumbo frames. Maybe you got lucky and some ethernet drivers
 default to accepting larger frames even if the MTU is 1500.
 
 
 -a


It is not the jumbo frame that makes this specific NIC work, I have to set the 
mtu
explicitely to make it work.

To make this notebook work in different departments, I need to use DHCP. At the 
moment I
have to set the mtu manually, disbaling and reenabling the NIC (ifconfig re0 
down,
ifconfig re0 mtu , ifconfig re0 up).

This seems to be strange. After that, the NIC seems to work as expected and the 
Laptop
has connection.

Oliver


signature.asc
Description: PGP signature

Re: CURRENT: EFI boot failure

Am Tue, 16 Sep 2014 17:32:12 -0400
Ed Maste ema...@freebsd.org schrieb:

 On 16 September 2014 17:03, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
  In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What 
  is the
  difference? Is the efi partition FAT?
 
 An EFI system partition (ESP) is a FAT-formatted partition with a
 specific GPT or MBR identifier and file system hierarchy; EFI firmware
 will try to load /EFI/BOOT/BOOTX64.EFI from the ESP.
 
 boot1.efi is an EFI application - that is, a PECOFF format binary.  It
 searches for a UFS filesystem and loads loader.efi from that.  It is
 intended to simplify the UEFI boot process, so that loader.efi, the
 .4th files, loader.conf etc. do not all need to be installed in the
 ESP.

Thank you very much for the explanation. Well, since I never see the loader 
screen as we
are used to, were is that gone? There are no boot options anymore (like single 
user mode,
ACPI off et cetera). Is this intended?

Besides, checking both boot1.efi and loader.efi with file() shows something like
loader.efi: PE32+ executable (EFI application) x86-64 (stripped to external 
PDB), for MS
Windows. So both are PECOFF format files?

 
 boot1.efifat is a FAT filesystem image that contains a copy of
 boot1.efi as /EFI/BOOT/BOOTX64.EFI.  It exists so that the installer
 can treat it as opaque bootcode, like other boot schemes.  It's
 certainly possible to create a partition, use newfs_msdos to format
 it, and copy in boot1.efi instead.

All right, here you lost me ... sorry. The partition created by the installes 
with type
efi is then the /EFI/ partition, which then contains a folder BOOT and in 
which the
boot1.efi is located? 
As I understand, I can manually mount this partition as FAT and copy boot1.efi 
as
BOOTX64.EFI into it? This knowledge could come in handy if something goes very 
bad.

 
  It is one disk, dedicated to FreeBSD (a laptop disk). Is there any 
  documentation
  readable for non-developer for that matter? I'm curious about how EFI works 
  on
  FreeBSD.
 
 Better user-facing documentation is in progress; for now the best
 source is probably the wik.

Thank you.


signature.asc
Description: PGP signature

Re: CURRENT: EFI boot failure

Am Wed, 17 Sep 2014 01:25:07 +0300
Andriy Gapon a...@freebsd.org schrieb:

 On 17/09/2014 00:32, Ed Maste wrote:
  On 16 September 2014 17:03, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
  In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? 
  What is the
  difference? Is the efi partition FAT?
  
  An EFI system partition (ESP) is a FAT-formatted partition with a
  specific GPT or MBR identifier and file system hierarchy; EFI firmware
  will try to load /EFI/BOOT/BOOTX64.EFI from the ESP.
 
 A very useful read about how EFI boot process works and how different OSes 
 boot
 on top of it:
 http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html

Great!

 
  boot1.efi is an EFI application - that is, a PECOFF format binary.  It
  searches for a UFS filesystem and loads loader.efi from that.  It is
  intended to simplify the UEFI boot process, so that loader.efi, the
  .4th files, loader.conf etc. do not all need to be installed in the
  ESP.
  
  boot1.efifat is a FAT filesystem image that contains a copy of
  boot1.efi as /EFI/BOOT/BOOTX64.EFI.  It exists so that the installer
  can treat it as opaque bootcode, like other boot schemes.  It's
  certainly possible to create a partition, use newfs_msdos to format
  it, and copy in boot1.efi instead.
  
  It is one disk, dedicated to FreeBSD (a laptop disk). Is there any 
  documentation
  readable for non-developer for that matter? I'm curious about how EFI 
  works on
  FreeBSD.
  
  Better user-facing documentation is in progress; for now the best
  source is probably the wik.
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
  
 
 




signature.asc
Description: PGP signature

Re: zpool: multiple IDs, CURRENT drops all pools after reboot

Am Tue, 16 Sep 2014 22:06:36 +0100
Steven Hartland kill...@multiplay.co.uk schrieb:

  On of my backup drives dedicated to a ZPOOL is faulting and showing up 
  multiple ID.
  The only working ID is id: 257822624560506537.
  
  FreeBSD CURRENT with three ZFS disks and only 4GB of RAM is very flaky 
  regarding
  this issue: today, tow times the whole poolset vanishes after a reboot. 
  Giving the
  box 8 GB total and rebooting doens't show the problem, it gets more 
  frequent when
  reducing the RAM to 4GB (FreeBSD 11.0-CURRENT #2 r271684: Tue Sep 16 
  20:41:47 CEST
  2014). This is a bit spooky.
  
  Below the faulted harddrive. I guess the drive/pool below shown triggers 
  somehow the
  loss of all other pools (I have to import the other pools, which do not 
  have any
  defects, but they they drop out after a reboot and vanish).
  
  Is there a way getting rid of the faulty IDs without destroying the pool?
  
  Regards,
  
  Oliver 
  
   root@thor: [/etc] zpool import
 pool: BACKUP00
   id: 9337833315545958689
state: FAULTED
   status: One or more devices contains corrupted data.
   action: The pool cannot be imported due to damaged devices or data.
  The pool may be active on another system, but can be imported using
  the '-f' flag.
 see: http://illumos.org/msg/ZFS-8000-5E
   config:
  
  BACKUP00   FAULTED  corrupted data
8544670861382329237  UNAVAIL  corrupted data
  
 pool: BACKUP00
   id: 257822624560506537
state: ONLINE
   action: The pool can be imported using its name or numeric identifier.
   config:
  
  BACKUP00ONLINE
ada3p1ONLINE
  
 
 Might be a long shot but check out the patches on:
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594
 
 Specifically:
 https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147070
 
 And if that doesn't work:
 https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147286
 
 The second has all the changes from the first with the addition
 of some changes which dynamically size the max dirty data.
 
 These changes are in discussion and its likely the additions
 in the second patch aren't the right direction but they
 have been reported to show good improvements under high
 memory pressure for certain workloads, so would be interesting
 to see if they help with your problem.
 
 All that said you shouldnt end up with corrupt data no matter
 what.
 
 Are there any other symptoms? Has memory been checked for
 faults etc?
 
 Regards
 Steve

The reason why my desktop has only 4 GB left is that I discovered memory 
corruption when
equipted with 8 GB - there occured a strange bit flip. I can not assure that by 
ripping
off 4 GB (2 times 2GB, it is an old C2D/P45 based box) the problem has gone. I 
susepct
a dying chipset - when overheated (at the moment BIOS shows 80 degrees 
Celsius), the
problem is more frequent.

But, besindes data corruption, with 4 GB left and 2 disks put together as a 
striped
JBOD with another disk as the backup device (the faulty one) is a pain in the 
ass since
the box starts swapping immediately when some action on the ZFS drives take 
place. The
plan is to keep that craveyward alive for the next 2 months until I can afford 
a new
system ;-)

But anyway, I'll try the patches.

Thanks,
Oliver  



signature.asc
Description: PGP signature

11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI

2014-09-15 Thread O. Hartmann


Trying to install and run FreeBSD 11.0-CURRENT
(FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Lenovo E540 
notebook
fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The NIC 
shows up as
active and with carrier when issuing ifconfig re0.

From a desktop machine, I tried to ping the system in question and I get a 
result with
missing packets:

ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
64 bytes from 192.168.0.130: icmp_seq=26 ttl=64 time=0.114 ms
64 bytes from 192.168.0.130: icmp_seq=41 ttl=64 time=0.130 ms
64 bytes from 192.168.0.130: icmp_seq=60 ttl=64 time=0.119 ms
64 bytes from 192.168.0.130: icmp_seq=80 ttl=64 time=0.119 ms
64 bytes from 192.168.0.130: icmp_seq=100 ttl=64 time=0.105 ms
64 bytes from 192.168.0.130: icmp_seq=116 ttl=64 time=0.135 ms
64 bytes from 192.168.0.130: icmp_seq=136 ttl=64 time=0.091 ms

DHCP configuration fails, since no DHCP offer is discovered.

I swapped the switches, the cabling and I had always the same results. I used 
another
Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) and that 
system
gets DHCP offer and is online.

Since the notebook is brandnew, the last thing I'll suspect is a defective 
NIC, so I'll
ask whether this phenomenon is known - or, if not, the results definititely 
would
indicate a broken NIC. 

Another point is the WiFI adaptor. This notebook is supposed to have a WiFi 
NIC, but it
doesn't get revealed by FreeBSD (I tried iwn/iwi without success). 

pciconf output below, sorry for the messy shape, it is a copy-and-paste from 
that immature
vt() terminal.

Has anyone successfully installed that type of Notebook with FreeBSD CURRENT 
using NIC
and Wifi?

Please CC me.


Regards
oh


[...]

none1@pci0:3:0:0:   class=0xff card=0x502817aa chip=0x522710ec rev=0x01 
hdr=0x00


vendor = 'Realtek Semiconductor Co., Ltd.'


bar   [10] = type Memory, range 32, base 0xf1e0, size 4096, enabled


cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0


cap 05[50] = MSI supports 1 message, 64 bit


cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1)


 speed 2.5(2.5) ASPM L0s/L1(L0s/L1)


ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected


ecap 0003[140] = Serial 1 0001004ce000


re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10 hdr=0x00


subclass   = ethernet


cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current
D0
di sabled(L0s/L1)


cap 11[b0] = MSI-X supports 4 messages, enabled

ecap 0001[100] = AER 2 0 fatal 0 non-fatal 4 corrected



ecap 001e[178] = unknown 1


class  = network


cap 05[d0] = MSI supports 1 message, 64 bit


ecap 0003[140] = Serial 1 ac7ba1a06fd6


signature.asc
Description: PGP signature

CURRENT: EFI boot failure

2014-09-15 Thread O. Hartmann


Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works for 
UEFI fine.
After I updated the sources to  r271649, recompiled world and kernel (as well as
installed), now I get stuck with the screen message:

 FreeBSD EFI boot block
   Loader path: /boot/loader.efi

and nothing happens. After a couple of minutes, the system reboots.

What happened and how can this problem be solved?


signature.asc
Description: PGP signature

Re: CURRENT: EFI boot failure

2014-09-15 Thread O. Hartmann

Am Mon, 15 Sep 2014 17:39:26 -0700
Nathan Whitehorn nwhiteh...@freebsd.org schrieb:

 
 On 09/15/14 17:36, Allan Jude wrote:
  On 2014-09-15 20:05, O. Hartmann wrote:
  Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works 
  for UEFI
  fine. After I updated the sources to  r271649, recompiled world and kernel 
  (as well
  as installed), now I get stuck with the screen message:
 
  FreeBSD EFI boot block
  Loader path: /boot/loader.efi
 
  and nothing happens. After a couple of minutes, the system reboots.
 
  What happened and how can this problem be solved?
 
  You might need to update the boot1.efi file on the UEFI partition (small
  FAT partition on the disk)
 
  I am not sure how 'in sync' boot1.efi (on the fat partiton) and
  loader.efi have to be.
 
  https://wiki.freebsd.org/UEFI
 
 
 boot1.efi is designed never to need updating. (It also hasn't changed 
 since April)
 -Nathan


But it has changed bytesize when I recompiled world with recent sources 
compared to the
boot.efi size from the USB image I installed from (revision see above).

How to update bootcode on UEFI layout? I created a GPT partition with type efi 
(1 GB) as
well as a 512KB partition typed freebsd-boot.

I'm new to EFI and the way the notebook now behaves is really strange. While 
the USB
drive image used to boot with new console enabled, it now boots again with the 
old
console and 800x640 resolution. This might indicate some minor but very 
effective mistake
I made.

Oliver


signature.asc
Description: PGP signature

Re: service doen't get started at boottime, but can start manually

2014-09-10 Thread O. Hartmann

Am Sun, 7 Sep 2014 11:16:37 -0500
Scot Hetzel swhet...@gmail.com schrieb:

 On Sun, Sep 7, 2014 at 10:44 AM, Scot Hetzel swhet...@gmail.com wrote:
  I created the rc.d/refdbd script by copying /etc/rc.d/inetd and make a
  few minor changes.
  This script (untested) should do what the scripts/refdb.in and
  scripts/refdbctl.in were doing:
 
  #!/bin/sh
  #
  # $FreeBSD$
  #
 
  # PROVIDE: refdbd
  # REQUIRE: LOGIN
  # KEYWORD: shutdown
 
  . /etc/rc.subr
 
  name=refdbd
  rcvar=refdbd_enable
  command=%%PREFIX%%/bin/${name}
  pidfile=/var/run/${name}.pid
  required_files=/etc/${name}.conf
 
 I missed required_files in my editing of the original script.
 
 If refdbd does have a configuration file, changes this to point to the
 correct file, otherwise this can be removed.
 
  extra_commands=reload
 
  load_rc_config $name
  run_rc_command $1
 
  Place the above in textproc/refdb/files/refdb.in, then add:
 
  USE_RC_SUBR= refdbd
 
  in textproc/refdb/Makefile.
 
 

It seems to me, that when a port installs a script appended with *.sh in 
etc/rc.d/, the
script gets executed anyway - regardless wether the service is enabled
in /etc/rc.conf[.local] or not. This is especially the case for the original 
port
textproc/refdb.

The reason why especially one particular machine rejected the startup of the 
service was:
I changed the script's name from refdb.sh to refdb and with the lack of the 
correct
syntax and definitions inside it, the system (11.0 CURRENT) did not start the 
service
while the other systems running refdb used the oldstyle refdb.sh script.

Just for the conclusion of the obscure (at least for me) behaviour.

Thanks for your time,

Oliver


signature.asc
Description: PGP signature

Re: [Bug 144203] textproc/refdb: network clients loop indefinitely when hitting Ctrl-D while client asks for passowrd

2014-09-09 Thread O. Hartmann

Am Tue, 09 Sep 2014 06:35:29 +
bugzilla-nore...@freebsd.org schrieb:

 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144203
 
 --- Comment #8 from John Marino mar...@freebsd.org ---
 FYI, I'm removing this port tonight.   We've waited long enough.
 


In the strain of a bug I reported I also tried to fix this port, since the prior
maintainer seems to have abandonded this great port.

I'm a bit pissed off about the rude tune I feel treated!

The developer has patched the original sources to meet some FreeBSD requirements
regarding a readline issue now fixed and especially some serious bugs in 
bib2ris and a
transforming/migrating tool using UTF-8 encodings for LaTeX codings. Since not 
all
patches are 100% tested (but they work graeat for me in a scientific 
environment), the
upstream developer hestiates creating the new tarball. 

As I documented with this PR, I'm wating for the developer to publish a new
tarball.

I spent lot of time to provide a workaround for fixing the lack of the new 
tarball and
some serious previously unresolved FreeBSD issues and the time I sacrificed is 
not only
working time! I mention this since I'm feeling put under pressure as the note 
sent to
me documents.

What is the policy of FreeBSD's port system? There are lots of ports waiting to 
be fixed
since they have serious issue, like silc-toolkit. Is this port also about to be 
deleted
or isn't there a lobby preventing this?

In a hurry, to prevent the destruction of the port textproc/refdb, I provided a 
patch.
The patch is a bit messy since I had to incorporate all changes made in the 
meanwhile
after creation of refdb-1.0.2.tar.gz (provided at:
http://sourceforge.net/projects/refdb/files/latest/download). 

Please see PR Bug 193484 - [textproc/refdb] Update port.

With regards,

oh


signature.asc
Description: PGP signature

service doen't get started at boottime, but can start manually


I use a service (textprox/refdb from ports, refdb_enable=YES in 
/etc/rc.conf.local)
that is supposed to startup at boottime. On one CURRENT system, running

 FreeBSD 11.0-CURRENT #3 r271210: Sat Sep  6 22:39:59 CEST 2014 amd64

the service is not started at boottime, but I can start the service manually via

service refdb start

I tried enabling rc_debug=YES in /etc/rc.conf but I do not see any failure of 
the start
attempt of that specific service in the logs or on the console. 

Is there an elegant way to debug rc.d and the startup procedure without having 
the system
reboot (I do not have jails or VM, sorry)?

oh


signature.asc
Description: PGP signature

Re: service doen't get started at boottime, but can start manually

Am Sun, 7 Sep 2014 15:33:42 +0800
Erich Dollansky er...@alogt.com schrieb:

 Hi,
 
 On Sun, 7 Sep 2014 09:03:21 +0200
 O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
  
  I use a service (textprox/refdb from ports, refdb_enable=YES
  in /etc/rc.conf.local) that is supposed to startup at boottime. On
  one CURRENT system, running
  
   FreeBSD 11.0-CURRENT #3 r271210: Sat Sep  6 22:39:59 CEST 2014 amd64
  
  the service is not started at boottime, but I can start the service
  manually via
  
  service refdb start
  
  I tried enabling rc_debug=YES in /etc/rc.conf but I do not see any
  failure of the start attempt of that specific service in the logs or
  on the console. 
  
  Is there an elegant way to debug rc.d and the startup procedure
  without having the system reboot (I do not have jails or VM, sorry)?
  
 could it be that the spelling in either rc.conf and the spelling in the
 actual script differ so that FreeBSD does not start it?
 
 Erich

No. If it would be the case, I guess starting it manually wouldn't work either. 
The fact
is that the port textproc/refdb uses a startup script named refdb.sh and by 
maintaining
the port and on the way to make it more CURRENT compliant, I started with 
renaming it to
refdb and it seems this is the culprit.

The script textproc/refdb uses is a bit awkward since it targets both *BSD and 
Linux
init/rc scripts and the initial rc.d/refddb scripts gives control to another 
script
called refdbctl which seems to perform all the stuff FreeBSD's /etc/rc.subr is 
providing.

I renamed the script back to refdb.sh by now and the service starts again as
expected.  I guess the spawning into a subshell fails somehow at that point 
when booting
the box.

Oliver 


signature.asc
Description: PGP signature

Re: service doen't get started at boottime, but can start manually

Am Sun, 7 Sep 2014 04:03:25 -0500
Scot Hetzel swhet...@gmail.com schrieb:

 On Sun, Sep 7, 2014 at 3:39 AM, Scot Hetzel swhet...@gmail.com wrote:
  I had a look at scripts/refdb.in, it is not a proper rc script for
  FreeBSD, as it is missing several keywords:
 
  # PROVIDE: - all scripts need this
  # REQUIRE:
  # BEFORE:
  # KEYWORD: - optional
 
  Which tells rcorder where to put refdb in the startup order.  Since
  these are missing, rcorder doesn't place it in the startup list.
 
 I looked again, and it is not rcorder, it's /etc/rc and /etc/rc.subr
 that determine which script to run.
 
 /etc/rc calls find_local_scripts_new from /etc/rc.subr.
 find_local_scripts_new checks each rc script to make sure that they
 have at least a # PROVIDE:  keyword.  If it does, then it adds that
 script to ${local_rc}.  Then /etc/rc runs:
 
 files=`rcorder /etc/rc.d/* ${local_rc}`
 
 to get the startup order for these scripts.  Then /etc/rc starts the
 scripts in the proper order.
 
 Since, /usr/local/etc/rc.d/refdb{,.sh.dist} is missing the # PROVIDE:
 , the script is skipped on startup.
 
 Since, rc.d/refdb is not a proper rc script, adding refdb_enable=YES
 to /etc/rc.conf{,.local} will not control the starting of this script.
 
 Someone should fix service, so that it checks the rc script has a #
 PROVIDE: , and displays an error message if it doesn't.

Hello Scott,

as the new maintainer of this port, I'm working on a solution, but first, I 
have to
understand the way this obscure rc-script system works. Thanks for your good 
explanation.
I tried to put PROVIDE/REQUIRE in the script, but I also changed refdb.sh - 
refdb
which, in the end, didn't work. The service IS started with refdb.sh in rc.d/. 

Since the original refdb.sh init script targets both Linux and *BSD and 
delegates the
starting, stopping et cetera to a script called refdbctl, the latter script 
needs to be
examinded and as far as I understand, most of its functionality is covered
by /etc/rc.cubr, except the part where refdbctl searches for the path of the 
PID file and
replaces the init/default path its configuration counterpart found in
prefix/etc/refdb/refdbdrc.

I guess, at the end FreeBSD doen't need the templated refdbctl/refdb.in (to be 
found in
the sources in scripts/).

If you'd like to have a look at it, I can send you the sekelton I've already 
prepared for
the refurbishment of the port.

Oliver


signature.asc
Description: PGP signature

Re: service doen't get started at boottime, but can start manually