On, Fri Oct 21, 2016, Dimitry Andric wrote:
> On 21 Oct 2016, at 20:47, Marcus von Appen <m...@freebsd.org> wrote:
> >
> > -CURRENT as of r307731 seems to have some serious flaw with its build
> > tool environment. Many ports fail to build with some error similar to
&g
On, Fri Oct 21, 2016, Marcus von Appen wrote:
> Hi,
>
> -CURRENT as of r307731 seems to have some serious flaw with its build
> tool environment. Many ports fail to build with some error similar to
> the following (devel/apr1):
>
> cc -emit-llvm -fno-strict-aliasin
On, Thu Sep 01, 2016, Andriy Voskoboinyk wrote:
> Hi everyone,
>
> rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged
> into a
> single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the code is
> available on https://github.com/s3erios/rtwn repository. Among bugfixes /
>
Hi,
-CURRENT as of r307731 seems to have some serious flaw with its build
tool environment. Many ports fail to build with some error similar to
the following (devel/apr1):
cc -emit-llvm -fno-strict-aliasing -pipe -march=native -DLIBICONV_PLUG
-fstack-protector -c -o .c.bco
cc: error: no input
On, Thu Sep 01, 2016, Andriy Voskoboinyk wrote:
> Hi everyone,
>
> rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged
> into a
> single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the code is
> available on https://github.com/s3erios/rtwn repository. Among bugfixes /
>
On, Mon Jun 27, 2016, Andriy Voskoboinyk wrote:
> Mon, 27 Jun 2016 20:06:20 +0300 було написано Marcus von Appen
> <m...@freebsd.org>:
>
> Hi,
>
> the attached patch may fix this issue (probably)
I'm getting downstream rates of around 300 to 500 kbit/s, so it's n
On, Mon Jun 27, 2016, Otacílio wrote:
[...]
> What is the revision that you are using? I have faced a similar problem
> on APLHA4, but now, on ALPHA5 it is working fine.
FreeBSD 11.0-ALPHA5 #3 r302191M: Sat Jun 25 14:21:12 CEST 2016
Note that rtwn and urtwn are using different firmware and a
On, Mon Jun 27, 2016, Adrian Chadd wrote:
> Heh, there isn't any 11n support in rtwn (and won't be until I unify
> rtwn and urtwn post-11.)
I do not know about that. My experience from pre-r302035 were 1-2 Mbit/s
downstream from some servers, but often enough just for a minute or two
before
Hi,
restarting the network interface for my rtwn(0)-based RTL8188CE card
causes a reproducible kernel panic:
# service netif restart
[...]
panic: Memory modified after free 0xf80005c22800(2048) val=8018 @
0xf80005c22800
[...]
Unread portion of the kernel message buffer:
panic: Memory
Hi,
thanks to previous efforts, the rtwn(0) connection for my RTL8188CE
wireless card is far more stable. It seems to come at the price of
relatively bad performance, though. After r302035 from avos@, I
can't get more than 500 kbit/s downstream from anywhere.
Let me know, what information is
Hi Andriy,
On, Tue Jun 14, 2016, Andriy Voskoboinyk wrote:
> Tue, 14 Jun 2016 08:24:01 +0300 було написано Marcus von Appen
> <m...@freebsd.org>:
>
> Hi!
>
> Try attached patch (adds some busdma synchronization,
> unloads data instead of descriptor in rtwn_tx_done() an
Hi,
I'm running into a somewhat weird issue with the rtwn driver
on CURRENT. It usually works for a couple of minutes (if there's
not too much of troughput happening) before the downstream and
upstream rates just "dry up" and the interface stops working.
It happens faster, if there are multiple
On, Mon May 16, 2016, Marcus von Appen wrote:
[...]
this one seems to provide some more information. I have no idea,
if both crash types are related or not.
Unread portion of the kernel message buffer:
rtwn0: can't map mbuf (error 12)
panic: Duplicate free of 0xf800c94c1300 from zone
Dear all,
thankfully -CURRENT supports the RTL8188CE wifi chipset via rtwn(0)
on the Thinkpad X230. Unfortunately the connection to the AP drops
nine times out of ten after transmitting a few kb. Trying to
reconnect via service netif restart will cause a panic:
panic: Memory modified after free
On, Wed Oct 29, 2014, Eitan Adler wrote:
On 28 October 2014 15:14, Baptiste Daroussin b...@freebsd.org wrote:
On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote:
Quoting John Baldwin j...@freebsd.org:
On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote:
Hello
Quoting John Baldwin j...@freebsd.org:
On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote:
Hello,
In short, nice kernel tasks people with C language skills can do in few
evenings.
https://wiki.freebsd.org/JuniorJobs
It is assumed you know how to obtain sources and build the
Alban Hertroys haram...@gmail.com:
On 2 September 2014 11:08, Julian Elischer jul...@freebsd.org wrote:
On 9/1/14, 8:03 PM, Andrew Berg wrote:
On 2014.09.01 21:39, Julian Elischer wrote:
sigh.. when are we as a project, all going to learn that reality in
business is
that you often need to
Brandon Allbery allber...@gmail.com:
On Tue, Sep 2, 2014 at 6:52 AM, Marcus von Appen m...@freebsd.org wrote:
It also should be noted that everyone had enough time to raise those issues
in the time between tthe announcement and now
If this is an issue that needed to be brought up
Steve Kargl s...@troutmask.apl.washington.edu:
[...]
Sigh. Adding USE_GCC isn't the solution.
% pan
Segmentation fault (core dumped)
% ldd /usr/local/bin/pan | grep ++
libstdc++.so.6 = /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000)
libc++.so.1 = /usr/lib/libc++.so.1
Joshua Isom jri...@gmail.com:
[...]
BSD: If you love something, set it free. If it comes back to you,
it was meant to be.
GPL: If you love something, set if free, but put a chain around
it's neck to make sure it doesn't get out of sight.
One of the best to-the-point explanations,
Daniel Gerzo dan...@freebsd.org:
On 27.06.2012 10:43, Doug Barton wrote:
On 06/27/2012 02:09 AM, Oleg Moskalenko wrote:
Doug, I'll post some performance figures, probably tomorrow.
That's great, thanks.
But I do not agree with you that we have to reproduce the old sort bugs.
It makes no
Hi,
I wonder, if I am correct with my assumption that the usb_ctl_report*
structures mentioned in uhid(4) have to be defined and created by the
code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(),
... calls.
In FreeBSD 800063 we defined them in the header files of the USB
subsystem.
On, Tue Nov 15, 2011, Alexander Motin wrote:
On 15.11.2011 21:29, Marcus von Appen wrote:
I wonder, if I am correct with my assumption that the usb_ctl_report*
structures mentioned in uhid(4) have to be defined and created by the
code portion that uses the USB_GET_REPORT(), USB_SET_REPORT
23 matches
Mail list logo
