- Original Message -
> Perhaps not, but they do support FreeBSD. I've started several support cases
> with FreeBSD-specific problems and they've fixed all so far.
>
Yes, it is not a blackhole of support. At $JOB, we got caught by the FreeBSD
specific issue of the busted timer that was f
On Mon, 5 Aug 2013 10:29:23 -0700
Craig Rodrigues wrote:
> On Sun, Aug 4, 2013 at 3:59 PM, Sam Fourman Jr. wrote:
>
> >
> >
> >
> > Craig,
> >
> > Thank you for getting back to me, I will get to work on this right away
> > and get you what you need.
> > but are we CERTAIN this panic could be fr
On Mon, Aug 05, 2013 at 05:52:01PM -0500, Bryan Venteicher wrote:
>
>
> - Original Message -
> > I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the
> > VMware tools package from VMware. Everything has been running great for
> > years.
> > (we skipped vSphere 5.0). Wh
On Mon, 5 Aug 2013, Davide Italiano wrote:
The LOR is a false positive.
See the comment in sys/ufs/ufs/ufs_dirhash.c
Also, switching motherboards is not related to this in any way. You'll
eventually hit that LOR report, unless you disabled WITNESS.
Ah, thank you Davide; sorry for the noise ...
Boris Samorodov writes:
> This note from /usr/src/UPDATING may be relevant:
> -
> 20130613:
> Some people report the following error after the switch to bmake:
>
> make: illegal option -- J
> usage: make [-BPSXeiknpqrstv] [-C directory] [-D vari
On Mon, Aug 5, 2013 at 4:24 PM, Sam Fourman Jr. wrote:
> I am going to respond to this before I forget
>
> I had the SAME exact LOR's with ath 9300 and I reported them,
> however I have since switched out motherboards and the LOR's have strangely
> diapered
>
>
> here is a full dmesg for a per
I am going to respond to this before I forget
I had the SAME exact LOR's with ath 9300 and I reported them,
however I have since switched out motherboards and the LOR's have strangely
diapered
here is a full dmesg for a perfectly working system
FreeBSD clang version 3.3 (tags/RELEASE_33/fin
Not sure if this is a known issue since I don't usually use UFS.
Yesterday I put current on an acer laptop with an i3 processor/4GB RAM
with UFS file system on a OCZ vertex 2 SSD and trim enabled via tunefs.
Below is the dmesg along with the LOR message at the bottom. I can
provide more info
- Original Message -
> I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the
> VMware tools package from VMware. Everything has been running great for
> years.
> (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the
> VMware tools driver or the em
On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote:
> On 05.08.2013 19:36, Luigi Rizzo wrote:
...
>
> [picking a post at random to reply in this thread]
> > tell whether or not we should bail out).
>
> Ideally we don't want to have any locks in the RX and TX path at all.
Ok i have r
On 05.08.2013 19:36, Luigi Rizzo wrote:
On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote:
I'm travelling back to San Jose today; poke me tomorrow and I'll brain
dump what I did in ath(4) and the lessons learnt.
The TL;DR version - you don't want to grab an extra lock in the
read/write paths
- Original Message -
> On Mon, Aug 5, 2013 at 8:19 PM, Adrian Chadd wrote:
>
> > No, brian said two things:
> >
> > * the flag, protected by the core lock
> > * per-queue flags
> >
>
> i see no mentions on per-queue flags on his email.
> This is the relevant part
>
Right, I just use
Hi,
I just wanted to let you know that data structures in sys/netinet6
now uses time_uptime instead of time_second. This should not be
user-visible, but if you notice there is something wrong with IPv6
after r253970, please let me know. Please do not forget to update
rtsold(8), rtadvd(8), a
On Mon, Aug 5, 2013 at 8:46 PM, Jack Vogel wrote:
> What do you think about this change?
>
>
looks good to me. but there is no need to rush, especially
it will be nice if all interested parties agree on an approach
and possibly even naming.
I do not have any specific test case but the problem ca
On Sun, Aug 04, 2013 at 07:12:17PM -0500, Bryan Venteicher wrote:
> Hi,
>
> I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a
> lot of cleanup, bug fixes, new features, etc (+2000 new lines) along
> the way so there is not much of a resemblance left.
>
> The driver is in good en
On 05.08.2013 16:59, Bryan Venteicher wrote:
- Original Message -
i am slightly unclear of what mechanisms we use to prevent races
between interface being reconfigured (up/down/multicast setting, etc,
all causing reinitialization of the rx and tx rings) and
i) packets from the host st
On Mon, Aug 5, 2013 at 8:19 PM, Adrian Chadd wrote:
> No, brian said two things:
>
> * the flag, protected by the core lock
> * per-queue flags
>
i see no mentions on per-queue flags on his email.
This is the relevant part
What I've done in my drivers is:
* Lock the core mutex
On 08/05/2013 08:39, Mateusz Guzik wrote:
What happens to fd after the fork? Is it closed or simply remains
non-functional?
If the former, I suggest the patch is altered to leave fd with badfdops
in place so that epoll users get less surprised.
I will try to alter it this way. However, there i
What do you think about this change?
Cheers,
Jack
On Mon, Aug 5, 2013 at 10:58 AM, Luigi Rizzo wrote:
> On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel wrote:
>
>> Sigh, this ends up being ugly I'm afraid. I need some time to look at
>> code and think about it.
>>
>>
> actually the intel drivers
No, brian said two things:
* the flag, protected by the core lock
* per-queue flags
-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubs
On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel wrote:
> Sigh, this ends up being ugly I'm afraid. I need some time to look at code
> and think about it.
>
>
actually the intel drivers seem in decent shape,
especially if we reuse IFF_DRV_RUNNING as the reset flag
and the core+queue lock in the control
Sigh, this ends up being ugly I'm afraid. I need some time to look at code
and think about it.
Jack
On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote:
> On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote:
>
> > I'm travelling back to San Jose today; poke me tomorrow and I'll brain
> > dump
On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote:
> .. and I bet it's not a design pattern, and this is total conjecture on my
> part:
>
> * the original drivers weren't SMP safe;
> * noone really sat down and figured out how to correctly synchronise
> all of this stuff;
> * people did the mini
On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote:
> I'm travelling back to San Jose today; poke me tomorrow and I'll brain
> dump what I did in ath(4) and the lessons learnt.
>
> The TL;DR version - you don't want to grab an extra lock in the
> read/write paths as that slows things down. Reuse
On Sun, Aug 4, 2013 at 3:59 PM, Sam Fourman Jr. wrote:
>
>
>
> Craig,
>
> Thank you for getting back to me, I will get to work on this right away
> and get you what you need.
> but are we CERTAIN this panic could be from VIMAGE? I totally thought I
> had a # infront of that line when I built this
.. and I bet it's not a design pattern, and this is total conjecture on my part:
* the original drivers weren't SMP safe;
* noone really sat down and figured out how to correctly synchronise
all of this stuff;
* people did the minimum amount of work to keep the driver from
immediately crashing, bu
I'm travelling back to San Jose today; poke me tomorrow and I'll brain
dump what I did in ath(4) and the lessons learnt.
The TL;DR version - you don't want to grab an extra lock in the
read/write paths as that slows things down. Reuse the same per-queue
TX/RX lock and have:
* a reset flag that is
On 08/05/13 09:15, Luigi Rizzo wrote:
> On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote:
>
>> On 5 August 2013 07:59, Bryan Venteicher
>> wrote:
>>
>>> What I've done in my drivers is:
>>> * Lock the core mutex
>>> * Clear IFF_DRV_RUNNING
>>> * Lock/unlock each queue's lock
>>
>> .. and
On Sun, 4 Aug 2013 18:59:56 -0400
"Sam Fourman Jr." wrote:
> On Sun, Aug 4, 2013 at 6:52 PM, Craig Rodrigues wrote:
>
> > On Sun, Aug 4, 2013 at 12:33 PM, Sam Fourman Jr. wrote:
> >
> >> hello list,
> >>
> >> could someone help me figure out why this machine kernel paniced?
> >> I have a full c
05.08.2013 19:33, Robert Huff пишет:
> cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x
> /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src/make.amd64/bmake
> || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64
> TARGET_ARCH=amd64 buildworld
> usage: bmake [-BeikN
On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote:
> On 5 August 2013 07:59, Bryan Venteicher
> wrote:
>
> > What I've done in my drivers is:
> > * Lock the core mutex
> > * Clear IFF_DRV_RUNNING
> > * Lock/unlock each queue's lock
>
> .. and I think that's the only sane way of doing it.
On Mon, Aug 5, 2013, at 10:36, Sam Fourman Jr. wrote:
>
> epoll is needed to get the linux version of plex media server working in
> FreeNAS,
> however in the last month or so it looks as if a FreeBSD native app has
> been released
>
I'm working closely with Elan (head of Plex) and expect to be
On 5 August 2013 07:59, Bryan Venteicher wrote:
> What I've done in my drivers is:
> * Lock the core mutex
> * Clear IFF_DRV_RUNNING
> * Lock/unlock each queue's lock
.. and I think that's the only sane way of doing it.
I'm going to (soon) propose something similar for cxgbe/ixgbe as we
u
On Mon, Aug 05, 2013 at 05:25:56PM +0200, Roman Divacky wrote:
> On Mon, Aug 05, 2013 at 08:22:05AM -0700, Alfred Perlstein wrote:
> > On 8/5/13 2:36 AM, Yuri wrote:
> > > There is the patch, suggested by Roman Divacky, implementing Linux
> > > epoll(7) functionality:
> > > http://rys.vlakno.cz/~
> The glory days of the Linuxulator were around FreeBSD 6 when basically
> everything ran and often it ran much faster. We could really use a
> revival of this with the FreeBSD 10 release...
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.
On Mon, Aug 05, 2013 at 08:22:05AM -0700, Alfred Perlstein wrote:
> On 8/5/13 2:36 AM, Yuri wrote:
> > There is the patch, suggested by Roman Divacky, implementing Linux
> > epoll(7) functionality:
> > http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch
> >
> > This patch was suggested 5 yea
Craig Rodrigues writes:
> On Sat, Jun 1, 2013 at 10:47 AM, Robert Huff wrote:
>> cc -O -pipe -g -DNO_PWD_OVERRIDE -I/usr/src/usr.bin/bmake
>> -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H
>> -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H
>> -D_PATH_DEFSYSPATH=\".../share/mk:/usr/shar
On Mon, Aug 5, 2013, at 10:22, Alfred Perlstein wrote:
> The patch is small. I too am wondering why it's not committed, was
> there any push back?
>
The glory days of the Linuxulator were around FreeBSD 6 when basically
everything ran and often it ran much faster. We could really use a
revival
On 8/5/13 2:36 AM, Yuri wrote:
There is the patch, suggested by Roman Divacky, implementing Linux
epoll(7) functionality:
http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch
This patch was suggested 5 years ago and was discussed on emulation@:
http://lists.freebsd.org/pipermail/freebsd-em
- Original Message -
> i am slightly unclear of what mechanisms we use to prevent races
> between interface being reconfigured (up/down/multicast setting, etc,
> all causing reinitialization of the rx and tx rings) and
>
> i) packets from the host stack being sent out;
> ii) interrupts f
On Aug 5, 2013, at 2:23 AM, Luigi Rizzo wrote:
> i am slightly unclear of what mechanisms we use to prevent races
> between interface being reconfigured (up/down/multicast setting, etc,
> all causing reinitialization of the rx and tx rings) and
>
> i) packets from the host stack being sent out;
> Can you try to update the kernel to r253950 or later? This is
> probably because one of my recent commits broke IPv6 temporary
> address timer on non-IPv6 interfaces.
>
> -- Hiroki
>
I just built a kernel based on r253950, I will keep the list updated if
the panic happens again
--
Sam Fo
On Mon, 5 Aug 2013 13:36:29 +0300
Kimmo Paasiala wrote:
> On Mon, Aug 5, 2013 at 12:08 PM, Sergey V. Dyatko
> wrote:
> > On Sun, 4 Aug 2013 20:57:04 -0400
> > Glen Barber wrote:
> >
> >> On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote:
> >> > If you are disinclined to fix your commi
On Mon, Aug 5, 2013 at 12:08 PM, Sergey V. Dyatko
wrote:
> On Sun, 4 Aug 2013 20:57:04 -0400
> Glen Barber wrote:
>
>> On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote:
>> > If you are disinclined to fix your commit, then consider this
>> > an official request to back out revision 2525
There is the patch, suggested by Roman Divacky, implementing Linux
epoll(7) functionality:
http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch
This patch was suggested 5 years ago and was discussed on emulation@:
http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004409.html
h
Hello Brooks,
On Wed, Apr 17, 2013 at 03:01:27PM -0500, Brooks Davis wrote:
> On Wed, Apr 17, 2013 at 04:27:44AM -0500, Joshua Isom wrote:
> > On 4/17/2013 4:14 AM, Willy Offermans wrote:
> > > This is what I read in some of the articles or handbook as well. Can I
> > > reorder this linked list? C
On Sun, 4 Aug 2013 20:57:04 -0400
Glen Barber wrote:
> On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote:
> > If you are disinclined to fix your commit, then consider this
> > an official request to back out revision 252505.
> >
>
> You are the first and only one to complain after thi
On Sat, 3 Aug 2013 22:04:56 -0400
Glen Barber wrote:
> On Sun, Aug 04, 2013 at 08:10:09AM +0800, Erich Dollansky wrote:
> > doesn't this show again that svn came a bit early?
>
> No, it shows that people do not keep their third-party software up to
> date.
>
> Glen
>
what about devel/subversi
i am slightly unclear of what mechanisms we use to prevent races
between interface being reconfigured (up/down/multicast setting, etc,
all causing reinitialization of the rx and tx rings) and
i) packets from the host stack being sent out;
ii) interrupts from the network card being processed.
I th
49 matches
Mail list logo
