In reference to this FreeBSD forums post:
http://forums.freebsd.org/showpost.php?p=231135postcount=4
Would it be a good time to remove those from GENERIC since the
hardware they are for is becoming so seriously outdated?
There's always an option to load those drivers as modules if needed.
On 28.08.2013 21:42, Alexander Panyushkin wrote:
problem in load module i915kms.ko
if *kldload i915kms.ko* system is going to reboot
Are you able to obtain a kernel core dump? They're saved in /var/crash
during the next boot.
If you have one, could you please send the last core.txt? This file
Hello.
In the interval between revisions = r254887 to r255016
make delete-old broken
root@nonamehost:/ # cd /usr/src/
root@nonamehost:/usr/src # yes|make delete-old
make[1]: tools/build/mk/tools/build/mk/OptionalObsoleteFiles.inc line
1603: Malformed conditional (${MK_GNU_PATCH} == no) make[1]:
Hm! Are they dynamically loaded if you insert the cards?
(Ie, has devd been taught about them as appropriate?)
-adrian
On 29 August 2013 02:15, Kimmo Paasiala kpaas...@gmail.com wrote:
In reference to this FreeBSD forums post:
http://forums.freebsd.org/showpost.php?p=231135postcount=4
- Original Message
From: Ivan Klymenko fi...@ukr.net
To: freebsd-current@freebsd.org freebsd-current@freebsd.org
Subject: make delete-old broken
Date: 29/08/13 12:16
Hello.
In the interval between revisions gt;= r254887 to r255016
make delete-old broken
root@nonamehost:/ #
В Thu, 29 Aug 2013 13:42:13 +0200
Andreas Tobler andreast-l...@fgznet.ch пишет:
I can not say exactly at what revision it happened - but it was
noticed in revision r255016
Should be fixed now, 255018.
Gruss,
Andreas
Thank you.
___
On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote:
There are a number of other places in the kernel where migration to an rmlock
makes sense -- however, some care must be taken for four reasons: (1) while
read locks don't experience line contention, write locking becomes observably
On Thursday, August 29, 2013 6:56:53 am Adrian Chadd wrote:
Hm! Are they dynamically loaded if you insert the cards?
(Ie, has devd been taught about them as appropriate?)
These are drivers for the bridges, not for cards you plug into the bridges.
If you autoloaded them at all you would load
On Friday, August 23, 2013 6:18:40 pm Yuri wrote:
On 08/23/2013 13:36, Ian Lepore wrote:
I think the point is that devfs_ops_f provides several devfs-specific
methods and then inherits the rest by referencing the standard
vn_whatever functions. Since John recommended that you expose the
On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote:
On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote:
So I vote, let's not give ourselves the burden of lugging dead weight in
base
for another 5 years. (in 2017 do we still want to be worrying about gcc in
29.08.2013 12:24, Jean-Sébastien Pédron пишет:
On 28.08.2013 21:42, Alexander Panyushkin wrote:
problem in load module i915kms.ko
if *kldload i915kms.ko* system is going to reboot
Are you able to obtain a kernel core dump? They're saved in /var/crash
during the next boot.
If you have one,
On 29.08.2013 17:35, Alexander wrote:
in sysctl:
kern.coredump: 1
kern.corefile: /var/coredumps/%U.%N.%P.core
but coredump files not created.
How to set for creating core files?
You must add the following line to your /etc/rc.conf:
dumpdev=AUTO
Also add this line to your
On Aug 29, 2013, at 8:54 AM, John Baldwin wrote:
On Thursday, August 29, 2013 6:56:53 am Adrian Chadd wrote:
Hm! Are they dynamically loaded if you insert the cards?
(Ie, has devd been taught about them as appropriate?)
These are drivers for the bridges, not for cards you plug into the
On Aug 29, 2013, at 3:15 AM, Kimmo Paasiala wrote:
In reference to this FreeBSD forums post:
http://forums.freebsd.org/showpost.php?p=231135postcount=4
Would it be a good time to remove those from GENERIC since the
hardware they are for is becoming so seriously outdated?
There's
Hello All,
I am working on trying to resolve a build issue with devel/libvirt, and
posted to the libvirt mailing list, and received this feedback. Please read
this thread, and if you have any thoughts I would be interested in any
resolution.
Here is a link to the thread:
On Aug 29, 2013, at 8:57 AM, John Baldwin wrote:
On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote:
On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote:
So I vote, let's not give ourselves the burden of lugging dead weight in
base
for another 5 years. (in 2017 do
On 08/29/13 11:52, Warner Losh wrote:
On Aug 29, 2013, at 3:15 AM, Kimmo Paasiala wrote:
In reference to this FreeBSD forums post:
http://forums.freebsd.org/showpost.php?p=231135postcount=4
Would it be a good time to remove those from GENERIC since the
hardware they are for is becoming so
On Thursday, August 29, 2013 11:37:08 am Scott Long wrote:
On Aug 29, 2013, at 7:42 AM, John Baldwin j...@freebsd.org wrote:
On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote:
There are a number of other places in the kernel where migration to an
rmlock
makes sense --
On Aug 27, 2013, at 8:46 AM, Nathan Whitehorn wrote:
On 08/25/13 18:41, Gerald Pfeifer wrote:
On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote:
I object. Many ports that compiles perfectly on gcc 4.2.1 can't be
compiled with lang/gcc. I checked this once and the number of ports
that require
.. after tinkering in the USB world, i wonder what's wrong with this:
* created a basic markup / description language to encapsulate what PCI/USB
probing requires;
* generated both config files _and_ .c / .h files for drivers to include;
* have the kernel build process do .device_description -
On Monday, August 26, 2013 3:05:06 pm John Baldwin wrote:
On Monday, August 26, 2013 2:23:44 pm Davide Italiano wrote:
Please consider the following patch:
http://people.freebsd.org/~davide/review/socket_timeout.diff
I've tested it and it works OK. I got a timeout which is ~= 25ms using
On Aug 25, 2013, at 8:21 AM, Ian Lepore wrote:
On Sat, 2013-08-24 at 23:44 +0100, David Chisnall wrote:
On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
And i found PR about clang and mplayer: ports/176272
This PR contains log with build error log.
Please file clang
On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote:
I have not seen any convincing
argument as to why leaving GCC in the base for 10.x impedes anything.
Because clang isn't sufficient for so many non-x86 platforms we can't
really start using clang-specific features yet anyway.
On Aug 29, 2013, at 10:14 AM, Adrian Chadd wrote:
.. after tinkering in the USB world, i wonder what's wrong with this:
* created a basic markup / description language to encapsulate what PCI/USB
probing requires;
* generated both config files _and_ .c / .h files for drivers to include;
On Aug 29, 2013, at 11:02 AM, David Chisnall wrote:
On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote:
I have not seen any convincing
argument as to why leaving GCC in the base for 10.x impedes anything.
Because clang isn't sufficient for so many non-x86 platforms we can't
In reference to this FreeBSD forums post:
http://forums.freebsd.org/showpost.php?p=231135postcount=4
Would it be a good time to remove those from GENERIC since the
hardware they are for is becoming so seriously outdated?
There's always an option to load those drivers as
Hi guys,
This was corrected? :)
Best regards,
Em 28/08/13 21:27, Marcelo Gondim escreveu:
I noticed that in this revision 254890 the system load is not less
than 1.0. Revision 254497 did not occur.
FreeBSD growthinfo01.localdomain 10.0-CURRENT FreeBSD 10.0-CURRENT #0
r254890: Thu Aug 29
On Thursday, August 29, 2013 11:59:53 am Jason Helfman wrote:
Hello All,
I am working on trying to resolve a build issue with devel/libvirt, and
posted to the libvirt mailing list, and received this feedback. Please read
this thread, and if you have any thoughts I would be interested in any
On Thursday, August 29, 2013 11:39:45 am Jean-Sébastien Pédron wrote:
On 29.08.2013 17:35, Alexander wrote:
in sysctl:
kern.coredump: 1
kern.corefile: /var/coredumps/%U.%N.%P.core
but coredump files not created.
These control user process core dumps, not kernel crash dumps.
How to
On Thursday, August 29, 2013 1:02:06 pm David Chisnall wrote:
On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote:
To summarise the current issues:
Our libstdc++ is ancient. It supports C++98 well, it kind-of supports
C++03. It doesn't support C++11 at all and never will, nor
29.08.2013 18:39, Jean-Sébastien Pédron пишет:
On 29.08.2013 17:35, Alexander wrote:
in sysctl:
kern.coredump: 1
kern.corefile: /var/coredumps/%U.%N.%P.core
but coredump files not created.
How to set for creating core files?
You must add the following line to your /etc/rc.conf:
On Aug 29, 2013, at 7:42 AM, John Baldwin j...@freebsd.org wrote:
On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote:
There are a number of other places in the kernel where migration to an
rmlock
makes sense -- however, some care must be taken for four reasons: (1) while
read
On 29.08.2013 21:05, John Baldwin wrote:
On Thursday, August 29, 2013 11:59:53 am Jason Helfman wrote:
I am working on trying to resolve a build issue with devel/libvirt, and
posted to the libvirt mailing list, and received this feedback. Please read
this thread, and if you have any thoughts I
On 29.08.2013 22:16, Andrey Chernov wrote:
On 29.08.2013 21:05, John Baldwin wrote:
On Thursday, August 29, 2013 11:59:53 am Jason Helfman wrote:
I am working on trying to resolve a build issue with devel/libvirt, and
posted to the libvirt mailing list, and received this feedback. Please read
On 08/25/13 04:44, Hans Petter Selasky wrote:
On 08/24/13 20:21, George Mitchell wrote:
Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an
unending stream of debug output and effectively locks up the chip
scrolling the output on the display. Perhaps there are some specific
Hi,
It was known that bge(4) generated wrong TCP/UDP checksum when the
frame length was less then 60 bytes. So bge(4) implemented padding
workaround for such runt frames. bge(4) also ignored H/W assisted
TCP/UDP checksum result when the length of received frame was less
than 60 bytes. This
I track -CURRENT (mostly for bhyve) and have found between updates that
if_tap often requires different calling semantics to work... sometimes it
needs and IP ad sometimes it doesn't it s the primary problem (on the same
update it is consitent is only after installing new updates [not all new
37 matches
Mail list logo
