On 08/30/13 08:09, Lundberg, Johannes wrote:
What I got so far is this;
USB driver from current stops after
xhci0: 32 byte context size
While driver from 9.1 continues to the next step which is
usbus0 on xhci0
xhci0: usbpf: Attached
...
I can try adding some printf's in the code and see if I g
What I got so far is this;
USB driver from current stops after
xhci0: 32 byte context size
While driver from 9.1 continues to the next step which is
usbus0 on xhci0
xhci0: usbpf: Attached
...
I can try adding some printf's in the code and see if I get some more..
On Tuesday, August 27, 2013, Lu
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
ones]
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 worka
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
d
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. Plea
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 thou
On Aug 29, 2013, at 7:42 AM, John Baldwin 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 locks don
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.c
On Thursday, August 29, 2013 1:02:06 pm David Chisnall wrote:
> On 29 Aug 2013, at 15:57, John Baldwin 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 does it support
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
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.
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 07
> In reference to this FreeBSD forums post:
> http://forums.freebsd.org/showpost.php?p=231135&postcount=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 a
On Aug 29, 2013, at 11:02 AM, David Chisnall wrote:
> On 29 Aug 2013, at 15:57, John Baldwin 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 st
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 includ
On 29 Aug 2013, at 15:57, John Baldwin 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.
Apparently I h
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 wrote:
>>
>>> And i found PR about clang and mplayer: ports/176272
>>> This PR contains log with build error log.
>>
>> Please file clang bu
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 usi
.. 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 -> .c
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
>>> tha
On Thursday, August 29, 2013 11:37:08 am Scott Long wrote:
>
> On Aug 29, 2013, at 7:42 AM, John Baldwin 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 -- howeve
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=231135&postcount=4
>>
>> Would it be a good time to remove those from GENERIC since the
>> hardware they are for i
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." wrote:
>>
>>> So I vote, let's not give ourselves the burden of "lugging" dead weight in
>>> base
>>> for another 5 years. (in 2017 do
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:
https://www.redhat.com/ar
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=231135&postcount=4
>
> Would it be a good time to remove those from GENERIC since the
> hardware they are for is becoming so seriously outdated?
>
> There
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 in
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 /etc/sy
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 hav
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 expos
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 lo
On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote:
> On 24 Aug 2013, at 11:30, "Sam Fourman Jr." 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
> > base?)
>
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 observab
В Thu, 29 Aug 2013 13:42:13 +0200
Andreas Tobler пишет:
>
> > 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.
___
freebsd-current@f
- Original Message
From: Ivan Klymenko
To: freebsd-current@freebsd.org
Subject: make delete-old broken
Date: 29/08/13 12:16
> Hello.
> In the interval between revisions >= r254887 to r255016
> make delete-old broken
>
> root@nonamehost:/ # cd /usr/src/
> root@nonamehost:/usr/sr
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 wrote:
> In reference to this FreeBSD forums post:
>
> http://forums.freebsd.org/showpost.php?p=231135&postcount=4
>
> Would it be a
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]:
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
In reference to this FreeBSD forums post:
http://forums.freebsd.org/showpost.php?p=231135&postcount=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.
-Kim
39 matches
Mail list logo
