O. Hartmann | 30 Sep 08:13 2014
Picon
Picon

pkg/ports system terribly messed up?


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
(Continue reading)

Andriy Gapon | 30 Sep 07:47 2014
Picon

vt_suspend / vt_resume


I think that currently vt_suspend / vt_resume are called at quite unsuitable
times.  For example, vt_suspend performs a vt switch which requires cooperation
from an X server, but that could be problematic given that some devices may
already be suspended.
I believe that it is better to do what sc(4) does and use power_suspend /
power_resume event handlers instead of device_suspend / device_resume methods.
power_suspend event is posted when a kernel has not entered any special state yet.

What do you think?
--

-- 
Andriy Gapon
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
David Shane Holden | 30 Sep 05:40 2014
Picon

[PATCH] nscd

So, I've noticed nscd hasn't worked right for awhile now.  Since I
upgraded to 10.0 it never seemed to cache properly but I never bothered
to really dig into it until recently and here's what I've found.  In my
environment I have nsswitch set to use caching and LDAP as such:

group: files cache ldap
passwd: files cache ldap

The LDAP part works fine, but caching didn't on 10.0 for some reason.
On my 9.2 machines it works as expected though.  What I've found is in
usr.sbin/nscd/query.c

struct query_state *
init_query_state(int sockfd, size_t kevent_watermark, uid_t euid, gid_t
egid)
{
   ...
	memcpy(&retval->timeout, &s_configuration->query_timeout,
		sizeof(struct timeval));
   ...
}

s_configuration->query_timeout is an 'int' which is being memcpy'd into
a 'struct timeval' causing it to grab other parts of the s_configuration
struct along with the query_timeout value and polluting retval->timeout.
In this case it appears to be grabbing s_configuration->threads_num and
shoving that into timeout.tv_sec along with the query_timeout. This ends
up confusing nscd later on (instead of being 8 it ends up being set to
34359738376) and breaks it's ability to cache.  I've attached a patch to
set the retval->timeout properly and gets nscd working again.  I'm
(Continue reading)

Yonghyeon PYUN | 30 Sep 03:57 2014
Picon

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

Hi,
I've added support for QAC AR816x/AR817x ethernet controllers.  It
passed my limited testing and I need more testers.  You can find
patches from the following URLs.

http://people.freebsd.org/~yongari/alc/pci.quirk.diff
and
http://people.freebsd.org/~yongari/alc/alc.diff.20140930

pci.qurik.diff is to workaround silicon bug of AR816x. Without it
MSI/MSIX interrupt wouldn't work.  If you just want to use
legacy INTx interrupt you don't have to apply it but you have to
tell alc(4) not to use MSI/MSIX interrupt with tunables(
hw.alc.msi.disable and hw.alc.msix_disable).

alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172
and E2200 controllers.  It supports all hardware features except
RSS.  If you have any QAC AR816x/AR817x or old AR813x/AR815x
controllers please test and report how the diff works for you.
Thanks.
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Luigi Rizzo | 29 Sep 17:30 2014
Picon
Picon

capsicum and netmap ?


Hi,
while trying the netmap-enabled libpcap library with tcpdump, i
noticed it fails to return data on a kernel with capsicum (the
string "capability mode sandbox enabled" made me suspicious, and
removing the cap_*() calls from tcpdump.c seems to make things
work again).

Would anyone be able to point me what should be done in the netmap
kernel module to make it work with capsicum ?

I am sure the cambridge folks are very interested in this :)

cheers
luigi

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Michael Butler | 29 Sep 13:48 2014
Picon

SVN r272273 breaks 'dump'

It seems that the strptime changes broke the recognition of
/etc/dumpdates. Last night's level 2 dump turned into a level 0:

  DUMP: Date of this level 2 dump: Mon Sep 29 00:10:26 2014
  DUMP: Unknown intermediate format in /etc/dumpdates, line 1
  DUMP: Unknown intermediate format in /etc/dumpdates, line 1
  DUMP: Unknown intermediate format in /etc/dumpdates, line 1
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping snapshot of /dev/ada0s3a (/) to standard output
  DUMP: mapping (Pass I) [regular files]

	imb

Chris H | 28 Sep 23:37 2014

Mesa-9: configure: error: C compiler cannot create executables

Greetings,
 A recent install of RELENG_9, followed by a build|install world|kernel.
Returns the following error when attempting an make install of
x11/xorg-minimal

===>  Configuring for dri-9.1.7_5,2
configure: loading site script /usr/ports/Templates/config.site
checking build system type... amd64-portbld-freebsd9.3
checking host system type... amd64-portbld-freebsd9.3
checking target system type... amd64-portbld-freebsd9.3
checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p
checking for gawk... (cached) /usr/bin/awk
checking whether gmake sets $(MAKE)... yes
checking whether gmake supports nested variables... yes
checking for style of include used by gmake... GNU
checking for gcc... clang
checking whether the C compiler works... no
configure: error: in `/usr/ports/graphics/dri/work/Mesa-9.1.7':
configure: error: C compiler cannot create executables
See `config.log' for more details
===>  Script "configure" failed unexpectedly.
Please report the problem to x11 <at> FreeBSD.org [maintainer] and attach the
"/usr/ports/graphics/dri/work/Mesa-9.1.7/config.log" including the output of
the failure of your make command. Also, it might be a good idea to provide
an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** [do-configure] Error code 1

(Continue reading)

Mike. | 28 Sep 17:52 2014

(unknown)


I'm starting to look at FreeBSD 11-current to see what's coming soon.
 I have an older notebook that I use for test environments for
purposes such as this.  Unfortunately, the notebook won't boot up
from the install CD, there's a loop it cannot seem to get out of.  

Details are:

- The install CD was made from this image:
   FreeBSD-11.0-CURRENT-i386-20140918-r271779-disc1

- The dmesg for the notebook is at the end of this message.  The
dmesg was captured with FreeBSD 10.0.  In the dmesg, you can see the
following lines:

(aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00
00 00 00
(aprobe0:ata1:0:1:0): CAM status: Command timeout
(aprobe0:ata1:0:1:0): Error 5, Retry was blocked
run_interrupt_driven_hooks: still waiting after 60 seconds for
xpt_config
(aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00
00 00 00
(aprobe0:ata1:0:1:0): CAM status: Command timeout
(aprobe0:ata1:0:1:0): Error 5, Retry was blocked

which, while slowing down the boot process drastically, still allowed
the boot process to run to successful completion.

- When I try to boot using the FreeBSD 11-current install CD, that
(Continue reading)

José Pérez Arauzo | 28 Sep 09:34 2014

What do you use for kernel debugging?

Hello,
I am trying to track down a (deadlock?) issue in CURRENT via DDB. The kernel does
not complete hw probes on my Acer V5.

I get stuck on apic_isr looping which leads nowhere.

So I thought maybe things improve if I debug from another machine.

What do you use for kernel debugging? According to the handbook kgdb over serial
is a good option, do you agree? I'm on a netbook with no ethernet and no option
for firewire: can I have a USB / nullmodem setup to work?

I have no old-style uarts hardware anymore, as the handbook suggests...

Any idea is welcome before I buy extra hw. I have a USB to serial showing up as
/dev/cuaU0, do I need to grab another one and a nullmodem cable or there are better
alternatives? Thank you.

BR,

--
José Pérez Arauzo

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Tom Everett | 28 Sep 04:47 2014

SOEKRIS kernel config

I see there is no SOEKRIS config on the tree, here

https://svnweb.freebsd.org/base/head/sys/i386/conf/

I have attached one for addition to the tree.

-- 
A better world shall emerge based on faith and understanding  - Douglas
MacArthur
#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#    http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: head/sys/i386/conf/GENERIC 271137 2014-09-04 21:06:33Z markj $
(Continue reading)

Chris H | 28 Sep 01:22 2014

dmesg seems broken

Greetings,
 I'm building RELENG_9 recently. I installed, and updated source,
last night. I've just built world, and kernel. After (and before)
kernel install. I've found I'm missing from 14 to 40 lines from
the top of the dmesg(8) output. In either /var/log/messages, and
in /var/run/dmesg.boot.
Where can I get that information? Where was it sent? Why am I
not allowed to view it?

Thank you for all your time, and consideration.

--Chris

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"


Gmane