Re: FreeBSD 9.1 ix driver vlan problem

[Michiel Boland]

On 09/25/2013 20:03, Daniel Corbe wrote:

Why would disabling STP on the switch *shorten* the amount of time it takes for
the port to come up?  At least on Cisco switches, it takes ~45 seconds for the
switching topology to converge with STP disabled.  Shorter periods if you enable
portfast or uplinkfast.


What is meant, I believe, is that the port should be configured as an edge port 
("spanning-tree portfast [trunk]" in cisco lingo, "set edge" for junipers). You 
don't ever want to disable STP anywhere - that's just a recipe for disaster.


Cheers
Michiel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard

[Yonghyeon PYUN]

On Thu, Sep 26, 2013 at 02:31:30AM +, Thomas Mueller wrote:
> > It looks like 8168E-VL.
> > Could you try attached patch and show me the dmesg output(re(4) and
> > rgephy(4) only)? The patch was generated to support 8106E but it
> > will correctly show MAC revision number.
> 
> I assume I go to /usr/src and run
> patch < /home/arlene/computer/re.8106.diff 
> 

Yes.

> Then rebuild the kernel with -DNO_MODULES and install under a different name, 
> like kernelre?
> 

Rebuilding kernel should be enough. See
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html
for more information.

> I would install this on USB-stick installation, could do this for i386 
> USB-stick installation as well.
> 
> > > Somewhat later I got
> 
> > >  Memory modified after free 0xfe0011546800(2048) val=977e3dd
> > 4 @ 0xfe0011546800
> > > Memory modified after free 0xfe001153b800(2048) val= @ 
> > > 0xfe00115
> > 3b800
> > > Memory modified after free 0xfe0011524800(2048) val=977e3dd4 @ 
> > > 0xfe00115
> > 24800
> > > VESA: set_mode(): 24(18) -> 24(18)
> > > Memory modified after free 0xfe0011594000(2048) val=977e3dd4 @ 
> > > 0xfe00115
> > 94000
> 
> > The size(2048) indicates mbuf cluster which in turn means bad
> > things happened in re(4). I have no idea how this can happen
> > though.
> > If you assign static IP addressi to re(4), does the driver works as
> > expected?
> 
> I can try assigning a static address to re4, not really sure how to set up 
> manually, though I did it long ago in Slackware Linux.
> 
> I wouldn't have known size 2048 indicated something bad, though the message's 
> presence and system crash indicated that something was fouled up in memory.
> 
> Tom
> 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard

[Thomas Mueller]

> It looks like 8168E-VL.
> Could you try attached patch and show me the dmesg output(re(4) and
> rgephy(4) only)? The patch was generated to support 8106E but it
> will correctly show MAC revision number.

I assume I go to /usr/src and run
patch < /home/arlene/computer/re.8106.diff 

Then rebuild the kernel with -DNO_MODULES and install under a different name, 
like kernelre?

I would install this on USB-stick installation, could do this for i386 
USB-stick installation as well.

> > Somewhat later I got

> >  Memory modified after free 0xfe0011546800(2048) val=977e3dd
> 4 @ 0xfe0011546800
> > Memory modified after free 0xfe001153b800(2048) val= @ 
> > 0xfe00115
> 3b800
> > Memory modified after free 0xfe0011524800(2048) val=977e3dd4 @ 
> > 0xfe00115
> 24800
> > VESA: set_mode(): 24(18) -> 24(18)
> > Memory modified after free 0xfe0011594000(2048) val=977e3dd4 @ 
> > 0xfe00115
> 94000

> The size(2048) indicates mbuf cluster which in turn means bad
> things happened in re(4). I have no idea how this can happen
> though.
> If you assign static IP addressi to re(4), does the driver works as
> expected?

I can try assigning a static address to re4, not really sure how to set up 
manually, though I did it long ago in Slackware Linux.

I wouldn't have known size 2048 indicated something bad, though the message's 
presence and system crash indicated that something was fouled up in memory.

Tom

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Dmitry Morozovsky]

On Wed, 25 Sep 2013, Rumen Telbizov wrote:

> Thanks for the heads-up Oleg, although not the news that I was hoping for.
> 
> So what I am going to do right now is reinstall with 9.2 and recompile the
> driver with your patch.
> I'll come back to the list with my results.

FWIW, we're (with oleg@, yeah) using this patch on stable/9, so you're welcome 
to test this on your 9

It's supposedly way too late to try to include this fix into 9.2-R, but maybe 
it's worth the errata notice...


-- 
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: ma...@freebsd.org ]

*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Possible kqueue related issue on STABLE/RC.

[John-Mark Gurney]

Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 22:40 +0300:
> On Wed, Sep 25, 2013 at 09:19:54AM -0700, John-Mark Gurney wrote:
> > Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +0300:
> > > On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
> > > > I'd like to understand why you think protecting these functions w/
> > > > the _DETACHED check is correct...  In kern_event.c, all calls to
> > > > f_detach are followed by knote_drop which will ensure that the knote
> > > > is removed and free, so no more f_event calls will be called on that
> > > > knote..
> > > 
> > > My current belief is that what happens is a glitch in the
> > > kqueue_register(). After a new knote is created and attached, the kq
> > > lock is dropped and then f_event() is called. If the vnode is reclaimed
> > > or possible freed meantime, f_event() seems to dereference freed memory,
> > > since kn_hook points to freed vnode.
> > 
> > Well, if that happens, then the vnode isn't properly clearing up the
> > knote before it gets reclaimed...  It is the vnode's responsibility to
> > make sure any knotes that are associated w/ it get cleaned up properly..
> See below.
> 
> > 
> > > The issue as I see it is that vnode lifecycle is detached from the knote
> > > lifecycle.  Might be, only the second patch, which acquires a hold 
> > > reference
> > > on the vnode for each knote, is really needed.  But before going into any
> > > conclusions, I want to see the testing results.
> > 
> > The vnode lifecycle can't/shouldn't be detached from the knote lifecycle
> > since the knote contains a pointer to the vnode...  There is the function
> > knlist_clear that can be used to clean up knotes when the object goes
> > away..
> This is done from the vdropl() (null hold count) -> destroy_vpollinfo().
> But this is too late, IMO. vdropl() is only executing with the vnode
> interlock locked, and knote lock is vnode lock.  This way, you might
> get far enough into vdropl in other thread, while trying to operate on
> a vnode with zero hold count in some kqueue code path.
> 
> We do not drain the vnode lock holders when destroying vnode, because
> VFS interface require that anybody locking the vnode own a hold reference
> on it.  My short patch should fix exactly this issue, hopefully we will see.

Which clearly wasn't happening before...  With the above, and rereading
your patch, I understand how this patch should fix the issue and bring
the life cycle of the two back into sync...

> > I was looking at the code, is there a good reason why you do
> > VI_LOCK/VI_UNLOCK to protect the knote fields instead of getting it in
> > the vfs_knllock/vfs_knlunlock functions?  Because kq code will modify
> > the knote fields w/ only running the vfs_knllock/vfs_knlunlock functions,
> > so either the VI_LOCK/VI_UNLOCK are unnecessary, or should be moved to
> > vfs_knllock/vfs_knlunlock...
> 
> vfs_knllock() is fine. The problematic case if the
> VOP_{PRE,POST}->VFS_KNOTE->VN_KNOTE->KNOTE calls from the VOPs. If you
> look at the vfs_knl_assert_locked(), you would note that the function
> only asserts that vnode is locked, not that it is locked exclusively.
> This is because some filesystems started require from VFS to do e.g.
> VOP_WRITE() with the vnode only shared-locked, and KNOTE() is called
> with shared-locked vnode lock.
> 
> The vfs_knllock() obtain the exclusive lock on the vnode, so kqueue
> callers are fine. Taking vnode interlock inside the filters provides
> enough exclusion for the VOP callers.

Ahh, ok, makes sense now..  Clearly I need to learn more about the
VFS/vnope system.. :)

Thanks for the explanations...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Rumen Telbizov]

Thanks for the heads-up Oleg, although not the news that I was hoping for.

So what I am going to do right now is reinstall with 9.2 and recompile the
driver with your patch.
I'll come back to the list with my results.

It would be really nice if Jack et al could test that patch themselves and
endorse/incorporate
into future FreeBSD releases. From the comments I am not sure if Jack
really approves on
it or there's a better way of fixing things.

Thank you,
Rumen Telbizov


On Wed, Sep 25, 2013 at 11:32 AM, Oleg Bulyzhin  wrote:

> On Wed, Sep 25, 2013 at 11:14:38AM -0700, Rumen Telbizov wrote:
>
> > Next steps:
> > 1. I will reinstall this machine with the latest 9.2 and repeat the tests
> > see what happens.
>
> I didnt test 9.2 but i checked recent HEAD - it has vlan problem too.
>
> --
> Oleg.
>
> 
> === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===
> 
>
>


-- 
Rumen Telbizov
Unix Systems Administrator 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Package build out to FTP distribution process

[grarpamp]

Can someone please describe the FreeBSD package building and
publishing to FTP process?

Consider the following representative directories...

ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.2-release/All/
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/All/

I'm not really interested in the release hierarchy, since other
than some kind of urgent fix, it has been a onetime build and publish
event and it ages with every future commit. It's process is fairly obvious.


Now for the 'stable' hierarchy, that is updated over time.
But how, under what policy and process, etc?

What determines when an update is pushed out?
Are there some minimum set of pkg that must build for it to be
pushed?

There must be some interim builds going on, where is the output
from those? Can it be made accessible via web?

Why is the update frequency so low and erratic?

Is there some kind of strategic signoff behind the name 'stable'
or is it just a reasonably named dumping area for a build from
ports HEAD?

Are there groups focused on running builds and squashing dependency
checkpoints?


I think of all the users who wish to use packages but perhaps cannot
because...
- months can go by before a popular package reappears from having
gone missing.
- the port itself may be a current version, which means somewhere
there is a good build with it, but the published package is a rather
old version for a long time.
- something in ports may not appear as a package but may
not be pkg banned, perhaps due to the above.

So in general, what is the process behind populating the stable
hierarchies of packages?

And how can and what are the improvements to be made?
Perhaps specifically regarding frequency and completeness.
But also in general.
Is this all wiki'd somewhere?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Possible kqueue related issue on STABLE/RC.

[Konstantin Belousov]

On Wed, Sep 25, 2013 at 09:19:54AM -0700, John-Mark Gurney wrote:
> Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +0300:
> > On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
> > > I'd like to understand why you think protecting these functions w/
> > > the _DETACHED check is correct...  In kern_event.c, all calls to
> > > f_detach are followed by knote_drop which will ensure that the knote
> > > is removed and free, so no more f_event calls will be called on that
> > > knote..
> > 
> > My current belief is that what happens is a glitch in the
> > kqueue_register(). After a new knote is created and attached, the kq
> > lock is dropped and then f_event() is called. If the vnode is reclaimed
> > or possible freed meantime, f_event() seems to dereference freed memory,
> > since kn_hook points to freed vnode.
> 
> Well, if that happens, then the vnode isn't properly clearing up the
> knote before it gets reclaimed...  It is the vnode's responsibility to
> make sure any knotes that are associated w/ it get cleaned up properly..
See below.

> 
> > The issue as I see it is that vnode lifecycle is detached from the knote
> > lifecycle.  Might be, only the second patch, which acquires a hold reference
> > on the vnode for each knote, is really needed.  But before going into any
> > conclusions, I want to see the testing results.
> 
> The vnode lifecycle can't/shouldn't be detached from the knote lifecycle
> since the knote contains a pointer to the vnode...  There is the function
> knlist_clear that can be used to clean up knotes when the object goes
> away..
This is done from the vdropl() (null hold count) -> destroy_vpollinfo().
But this is too late, IMO. vdropl() is only executing with the vnode
interlock locked, and knote lock is vnode lock.  This way, you might
get far enough into vdropl in other thread, while trying to operate on
a vnode with zero hold count in some kqueue code path.

We do not drain the vnode lock holders when destroying vnode, because
VFS interface require that anybody locking the vnode own a hold reference
on it.  My short patch should fix exactly this issue, hopefully we will see.

> 
> I was looking at the code, is there a good reason why you do
> VI_LOCK/VI_UNLOCK to protect the knote fields instead of getting it in
> the vfs_knllock/vfs_knlunlock functions?  Because kq code will modify
> the knote fields w/ only running the vfs_knllock/vfs_knlunlock functions,
> so either the VI_LOCK/VI_UNLOCK are unnecessary, or should be moved to
> vfs_knllock/vfs_knlunlock...

vfs_knllock() is fine. The problematic case if the
VOP_{PRE,POST}->VFS_KNOTE->VN_KNOTE->KNOTE calls from the VOPs. If you
look at the vfs_knl_assert_locked(), you would note that the function
only asserts that vnode is locked, not that it is locked exclusively.
This is because some filesystems started require from VFS to do e.g.
VOP_WRITE() with the vnode only shared-locked, and KNOTE() is called
with shared-locked vnode lock.

The vfs_knllock() obtain the exclusive lock on the vnode, so kqueue
callers are fine. Taking vnode interlock inside the filters provides
enough exclusion for the VOP callers.


pgpmOgoOWL9Qn.pgp
Description: PGP signature

Only one CPU core detected on Supermicro E3-1240 v3

[Marián Černý]

Hello,

I am trying to install FreeBSD 9.2-RC4 on Supermicro server with Intel Xeon 
E3-1240 v3 processor. The processor has 4 cores with 8 threads. However only 
one core is detected (with two threads):

FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 SMT threads
cpu0 (BSP): APIC ID:  0
cpu1 (AP): APIC ID:  1

The motherboard is Supermicro X10SLM-F. All cores are enabled in BIOS and the 
latest firmware is installed (version 1.1a, Build Date 08/20/2013).

Output from dmesg is available here: 
https://www.dropbox.com/s/u7hp8mlq2wo3oi5/dmesg.txt

I have tried FreeBSD 9.1 as well and it behaves the same - only one core is 
detected.

What can I do so that all cores are properly detected?

Marian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Oleg Bulyzhin]

On Wed, Sep 25, 2013 at 11:14:38AM -0700, Rumen Telbizov wrote:

> Next steps:
> 1. I will reinstall this machine with the latest 9.2 and repeat the tests
> see what happens.

I didnt test 9.2 but i checked recent HEAD - it has vlan problem too.

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Rumen Telbizov]

Jack,

Can you reproduce this problem yourself? Does it make sense to experience
this behavior?

Thanks,
Rumen Telbizov


On Wed, Sep 25, 2013 at 11:23 AM, Jack Vogel  wrote:

>
> Thanks for the investigation, I guess what I'm wondering the most right
> now is if the patch from
> Oleg is a good change in general, so any others that can test and give me
> results would be appreciated.
>
> Thanks,
>
> Jack
>
> On Wed, Sep 25, 2013 at 11:14 AM, Rumen Telbizov wrote:
>
>> Hi Jack,
>>
>> Thanks for the suggestions and looking into this.
>> Here are a few additional bits of information that you requested:
>>
>> 1. We did disable spanning tree on the switch port and the result of that
>> is that basically now creating/destroying a vlan on the ix interface makes
>> it freeze for about 3 seconds from previously 6.
>> 2. I brought manually the physical interface down (ifconfig ix1 down) and
>> then up and measured the time it took for the interface on the switch to
>> show as up - and that was again about 3 seconds. So basically it seems to
>> me like that's how long it normally takes for a link to be negotiated.
>> 3. We tweaked a setting on the switch which instructs the port to be down
>> for 5 seconds before it's considered down. Then repeated the test again and
>> the result was that now the "freeze" period got reduced to 1.5 seconds and
>> no ping packets were lost but one of the packets returned with 1500 ms
>> delay. My guess on this one is that since the switch ignored the flapping
>> of the interface, bringing it back up was much faster. So it does mask the
>> problem somewhat but it is still there - the interface seems to go down.
>>
>> Next steps:
>> 1. I will reinstall this machine with the latest 9.2 and repeat the tests
>> see what happens.
>> 2. If the previous one fails - I'll try the patch that Oleg sent. Thanks
>> a lot for providing that patch.
>>
>> I'll update this list with more findings.
>>
>> Thank you,
>> Rumen Telbizov
>>
>>
>>
>> On Wed, Sep 25, 2013 at 10:01 AM, Jack Vogel  wrote:
>>
>>> Rumen,
>>>
>>> I'd like to know if you can check the spanning tree setting as Daniel
>>> mentioned and if that solves it,
>>> I do know that that can cause considerable delay in link transitions.
>>> Also, can you see if you see
>>> different behavior by going to the latest 9.2 bits?
>>>
>>> Oleg thanks for the patch, I will check it out and have my validation
>>> engineer do some tests and
>>> we'll get to the bottom of this.
>>>
>>> Jack
>>>
>>>
>>>
>>> On Wed, Sep 25, 2013 at 9:57 AM, Rumen Telbizov wrote:
>>>
 Thanks for the patch Oleg.
 I'll give it a try but I would also like to hear back from Jack.

 Oleg, can you confirm that you're experiencing the exact same
 problem/behavior? What kind of switch is connected on the other end?

 Thanks,
 Rumen Telbizov


 On Wed, Sep 25, 2013 at 9:40 AM, Oleg Bulyzhin 
 wrote:

 >
 > I'm running my ixgbe servers with attached patch.
 > It does solve this problem for me.
 >
 > --
 > Oleg.
 >
 > 
 > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===
 > 
 >
 >


 --
 Rumen Telbizov

 Unix Systems Administrator 
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to "
 freebsd-stable-unsubscr...@freebsd.org"

>>>
>>>
>>
>>
>> --
>> Rumen Telbizov
>> Unix Systems Administrator 
>>
>
>


-- 
Rumen Telbizov
Unix Systems Administrator 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Jack Vogel]

Thanks for the investigation, I guess what I'm wondering the most right now
is if the patch from
Oleg is a good change in general, so any others that can test and give me
results would be appreciated.

Thanks,

Jack

On Wed, Sep 25, 2013 at 11:14 AM, Rumen Telbizov  wrote:

> Hi Jack,
>
> Thanks for the suggestions and looking into this.
> Here are a few additional bits of information that you requested:
>
> 1. We did disable spanning tree on the switch port and the result of that
> is that basically now creating/destroying a vlan on the ix interface makes
> it freeze for about 3 seconds from previously 6.
> 2. I brought manually the physical interface down (ifconfig ix1 down) and
> then up and measured the time it took for the interface on the switch to
> show as up - and that was again about 3 seconds. So basically it seems to
> me like that's how long it normally takes for a link to be negotiated.
> 3. We tweaked a setting on the switch which instructs the port to be down
> for 5 seconds before it's considered down. Then repeated the test again and
> the result was that now the "freeze" period got reduced to 1.5 seconds and
> no ping packets were lost but one of the packets returned with 1500 ms
> delay. My guess on this one is that since the switch ignored the flapping
> of the interface, bringing it back up was much faster. So it does mask the
> problem somewhat but it is still there - the interface seems to go down.
>
> Next steps:
> 1. I will reinstall this machine with the latest 9.2 and repeat the tests
> see what happens.
> 2. If the previous one fails - I'll try the patch that Oleg sent. Thanks a
> lot for providing that patch.
>
> I'll update this list with more findings.
>
> Thank you,
> Rumen Telbizov
>
>
>
> On Wed, Sep 25, 2013 at 10:01 AM, Jack Vogel  wrote:
>
>> Rumen,
>>
>> I'd like to know if you can check the spanning tree setting as Daniel
>> mentioned and if that solves it,
>> I do know that that can cause considerable delay in link transitions.
>> Also, can you see if you see
>> different behavior by going to the latest 9.2 bits?
>>
>> Oleg thanks for the patch, I will check it out and have my validation
>> engineer do some tests and
>> we'll get to the bottom of this.
>>
>> Jack
>>
>>
>>
>> On Wed, Sep 25, 2013 at 9:57 AM, Rumen Telbizov wrote:
>>
>>> Thanks for the patch Oleg.
>>> I'll give it a try but I would also like to hear back from Jack.
>>>
>>> Oleg, can you confirm that you're experiencing the exact same
>>> problem/behavior? What kind of switch is connected on the other end?
>>>
>>> Thanks,
>>> Rumen Telbizov
>>>
>>>
>>> On Wed, Sep 25, 2013 at 9:40 AM, Oleg Bulyzhin  wrote:
>>>
>>> >
>>> > I'm running my ixgbe servers with attached patch.
>>> > It does solve this problem for me.
>>> >
>>> > --
>>> > Oleg.
>>> >
>>> > 
>>> > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===
>>> > 
>>> >
>>> >
>>>
>>>
>>> --
>>> Rumen Telbizov
>>>
>>> Unix Systems Administrator 
>>> ___
>>> freebsd-stable@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org
>>> "
>>>
>>
>>
>
>
> --
> Rumen Telbizov
> Unix Systems Administrator 
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Daniel Corbe]

Why would disabling STP on the switch *shorten* the amount of time it takes 
for the port to come up?  At least on Cisco switches, it takes ~45 seconds 
for the switching topology to converge with STP disabled.  Shorter periods 
if you enable portfast or uplinkfast.



-Original Message- 
From: Daniel Kalchev

Sent: Wednesday, September 25, 2013 4:31 AM
To: Rumen Telbizov
Cc: freebsd-stable@freebsd.org ; Jack Vogel
Subject: Re: FreeBSD 9.1 ix driver vlan problem


On 25.09.2013, at 02:16, Rumen Telbizov  wrote:




Example:
ifconfig vlan200 create  # this is OK
ifconfig vlan200 inet 1.2.3.1/30  vlan 200 vlandev ix1 description DEBUG #
this second line makes the rest of the vlans freeze for 6-7 seconds

On the switch side (Juniper) the physical interface flaps. There's nothing
in logs/dmesg.



Might be, you have spanning tree enabled on the switch port and when the 
interface "flaps" it needs time to converge. Disable spanning tree on the 
port and the reset will be very short.


Daniel

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Rumen Telbizov]

Hi Jack,

Thanks for the suggestions and looking into this.
Here are a few additional bits of information that you requested:

1. We did disable spanning tree on the switch port and the result of that
is that basically now creating/destroying a vlan on the ix interface makes
it freeze for about 3 seconds from previously 6.
2. I brought manually the physical interface down (ifconfig ix1 down) and
then up and measured the time it took for the interface on the switch to
show as up - and that was again about 3 seconds. So basically it seems to
me like that's how long it normally takes for a link to be negotiated.
3. We tweaked a setting on the switch which instructs the port to be down
for 5 seconds before it's considered down. Then repeated the test again and
the result was that now the "freeze" period got reduced to 1.5 seconds and
no ping packets were lost but one of the packets returned with 1500 ms
delay. My guess on this one is that since the switch ignored the flapping
of the interface, bringing it back up was much faster. So it does mask the
problem somewhat but it is still there - the interface seems to go down.

Next steps:
1. I will reinstall this machine with the latest 9.2 and repeat the tests
see what happens.
2. If the previous one fails - I'll try the patch that Oleg sent. Thanks a
lot for providing that patch.

I'll update this list with more findings.

Thank you,
Rumen Telbizov



On Wed, Sep 25, 2013 at 10:01 AM, Jack Vogel  wrote:

> Rumen,
>
> I'd like to know if you can check the spanning tree setting as Daniel
> mentioned and if that solves it,
> I do know that that can cause considerable delay in link transitions.
> Also, can you see if you see
> different behavior by going to the latest 9.2 bits?
>
> Oleg thanks for the patch, I will check it out and have my validation
> engineer do some tests and
> we'll get to the bottom of this.
>
> Jack
>
>
>
> On Wed, Sep 25, 2013 at 9:57 AM, Rumen Telbizov wrote:
>
>> Thanks for the patch Oleg.
>> I'll give it a try but I would also like to hear back from Jack.
>>
>> Oleg, can you confirm that you're experiencing the exact same
>> problem/behavior? What kind of switch is connected on the other end?
>>
>> Thanks,
>> Rumen Telbizov
>>
>>
>> On Wed, Sep 25, 2013 at 9:40 AM, Oleg Bulyzhin  wrote:
>>
>> >
>> > I'm running my ixgbe servers with attached patch.
>> > It does solve this problem for me.
>> >
>> > --
>> > Oleg.
>> >
>> > 
>> > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===
>> > 
>> >
>> >
>>
>>
>> --
>> Rumen Telbizov
>>
>> Unix Systems Administrator 
>> ___
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>>
>
>


-- 
Rumen Telbizov
Unix Systems Administrator 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Oleg Bulyzhin]

On Wed, Sep 25, 2013 at 09:57:07AM -0700, Rumen Telbizov wrote:
> Thanks for the patch Oleg.
> I'll give it a try but I would also like to hear back from Jack.
> 
> Oleg, can you confirm that you're experiencing the exact same
> problem/behavior? What kind of switch is connected on the other end?

It looks very similar. I've tested with dlink dgs-3620-28tc +
Cisco SFP-H10GB-CU1M and (i'm not sure here) with loopback to 2nd port of
Intel X520-DA2 card.
I've found 2 problems in current ixgbe driver:
1) few seconds link loss on vlan reconfiguration (both create/destroy).
2) if you have configured vlans over ix0 and then run
   ifconfig ix0 vlanhwfilter
   your vlans will stop working until you "touch" ix0 vlan configuration
   (create one more vlan or destroy existing one).

Patch solves both for me.

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Invitation: Hello Dear, @ Wed 25 Sep 2013 13:00 - 14:00 (tessykipkaly...@gmail.com)

[tessykipkaly...@gmail.com]

You have been invited to the following event.

Title: Hello Dear,
Hello Dear,
My name is Ms Tessy, a tall good looking young girl,so lovely and caring  
with good understanding.fair in complexion,care with good sharing,honesty.  
I saw your profile which interested me much and i decided to contact you. I  
really want to have a good friendship with you even if you have married we  
can be friends ,i have a reason of selecting you as my friend,pls if you  
wish to know more.Pls contact me through this my e-mail address ok ,We need  
to talk and know ourself more and equally share pictures to each other.hope  
to hear from you.

Please reply me with my e-mail address here
(tessykipka...@yahoo.com)
Yours New Friend
tessy Thank
When: Wed 25 Sep 2013 13:00 – 14:00 Eastern Time
Calendar: tessykipkaly...@gmail.com
Who:
(Guest list has been hidden at organiser's request)

Event details:  
https://www.google.com/calendar/event?action=VIEW&eid=aTI3bmRwbW51MGo0cWJlaGJyYWRnMmdib28gZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc&tok=MjUjdGVzc3lraXBrYWx5YTAxQGdtYWlsLmNvbTkwYmRkZmIyMjAxYzE4ZWY5MDJiZDgyMWU5YjQ5ZGZiZWI2ZTM2MzU&ctz=America/New_York&hl=en_GB


Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account  
freebsd-stable@freebsd.org because you are an attendee of this event.


To stop receiving future notifications for this event, decline this event.  
Alternatively, you can sign up for a Google account at  
https://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Jack Vogel]

Rumen,

I'd like to know if you can check the spanning tree setting as Daniel
mentioned and if that solves it,
I do know that that can cause considerable delay in link transitions. Also,
can you see if you see
different behavior by going to the latest 9.2 bits?

Oleg thanks for the patch, I will check it out and have my validation
engineer do some tests and
we'll get to the bottom of this.

Jack



On Wed, Sep 25, 2013 at 9:57 AM, Rumen Telbizov  wrote:

> Thanks for the patch Oleg.
> I'll give it a try but I would also like to hear back from Jack.
>
> Oleg, can you confirm that you're experiencing the exact same
> problem/behavior? What kind of switch is connected on the other end?
>
> Thanks,
> Rumen Telbizov
>
>
> On Wed, Sep 25, 2013 at 9:40 AM, Oleg Bulyzhin  wrote:
>
> >
> > I'm running my ixgbe servers with attached patch.
> > It does solve this problem for me.
> >
> > --
> > Oleg.
> >
> > 
> > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===
> > 
> >
> >
>
>
> --
> Rumen Telbizov
> Unix Systems Administrator 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Rumen Telbizov]

Thanks for the patch Oleg.
I'll give it a try but I would also like to hear back from Jack.

Oleg, can you confirm that you're experiencing the exact same
problem/behavior? What kind of switch is connected on the other end?

Thanks,
Rumen Telbizov


On Wed, Sep 25, 2013 at 9:40 AM, Oleg Bulyzhin  wrote:

>
> I'm running my ixgbe servers with attached patch.
> It does solve this problem for me.
>
> --
> Oleg.
>
> 
> === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===
> 
>
>


-- 
Rumen Telbizov
Unix Systems Administrator 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Oleg Bulyzhin]

I'm running my ixgbe servers with attached patch.
It does solve this problem for me.

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


Index: sys/dev/ixgbe/ixgbe.c
===
RCS file: /home/ncvs/src/sys/dev/ixgbe/ixgbe.c,v
retrieving revision 1.53.2.6.2.2
diff -u -r1.53.2.6.2.2 ixgbe.c
--- sys/dev/ixgbe/ixgbe.c	17 Nov 2012 08:47:49 -	1.53.2.6.2.2
+++ sys/dev/ixgbe/ixgbe.c	20 Sep 2013 12:39:27 -
@@ -1198,9 +1198,6 @@
 		IXGBE_WRITE_REG(hw, IXGBE_RDT(i), adapter->num_rx_desc - 1);
 	}
 
-	/* Set up VLAN support and filter */
-	ixgbe_setup_vlan_hw_support(adapter);
-
 	/* Enable Receive engine */
 	rxctrl = IXGBE_READ_REG(hw, IXGBE_RXCTRL);
 	if (hw->mac.type == ixgbe_mac_82598EB)
@@ -1284,6 +1281,9 @@
 	/* Initialize the FC settings */
 	ixgbe_start_hw(hw);
 
+	/* Set up VLAN support and filter */
+	ixgbe_setup_vlan_hw_support(adapter);
+
 	/* And now turn on interrupts */
 	ixgbe_enable_intr(adapter);
 
@@ -4736,7 +4736,8 @@
 	bit = vtag & 0x1F;
 	adapter->shadow_vfta[index] |= (1 << bit);
 	++adapter->num_vlans;
-	ixgbe_init_locked(adapter);
+	//ixgbe_init_locked(adapter);
+	ixgbe_setup_vlan_hw_support(adapter);
 	IXGBE_CORE_UNLOCK(adapter);
 }
 
@@ -4763,7 +4764,8 @@
 	adapter->shadow_vfta[index] &= ~(1 << bit);
 	--adapter->num_vlans;
 	/* Re-init to load the changes */
-	ixgbe_init_locked(adapter);
+	//ixgbe_init_locked(adapter);
+	ixgbe_setup_vlan_hw_support(adapter);
 	IXGBE_CORE_UNLOCK(adapter);
 }
 
@@ -4785,6 +4787,20 @@
 	if (adapter->num_vlans == 0)
 		return;
 
+	/* Setup the queues for vlans */
+	for (int i = 0; i < adapter->num_queues; i++) {
+		rxr = &adapter->rx_rings[i];
+		/* On 82599 the VLAN enable is per/queue in RXDCTL */
+		if (hw->mac.type != ixgbe_mac_82598EB) {
+			ctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(i));
+			ctrl |= IXGBE_RXDCTL_VME;
+			IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(i), ctrl);
+		}
+		rxr->vtag_strip = TRUE;
+	}
+
+	if ((ifp->if_capenable & IFCAP_VLAN_HWFILTER) == 0)
+		return;
 	/*
 	** A soft reset zero's out the VFTA, so
 	** we need to repopulate it now.
@@ -4803,18 +4819,6 @@
 	if (hw->mac.type == ixgbe_mac_82598EB)
 		ctrl |= IXGBE_VLNCTRL_VME;
 	IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, ctrl);
-
-	/* Setup the queues for vlans */
-	for (int i = 0; i < adapter->num_queues; i++) {
-		rxr = &adapter->rx_rings[i];
-		/* On 82599 the VLAN enable is per/queue in RXDCTL */
-		if (hw->mac.type != ixgbe_mac_82598EB) {
-			ctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(i));
-			ctrl |= IXGBE_RXDCTL_VME;
-			IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(i), ctrl);
-		}
-		rxr->vtag_strip = TRUE;
-	}
 }
 
 static void
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Possible kqueue related issue on STABLE/RC.

[John-Mark Gurney]

Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +0300:
> On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
> > I'd like to understand why you think protecting these functions w/
> > the _DETACHED check is correct...  In kern_event.c, all calls to
> > f_detach are followed by knote_drop which will ensure that the knote
> > is removed and free, so no more f_event calls will be called on that
> > knote..
> 
> My current belief is that what happens is a glitch in the
> kqueue_register(). After a new knote is created and attached, the kq
> lock is dropped and then f_event() is called. If the vnode is reclaimed
> or possible freed meantime, f_event() seems to dereference freed memory,
> since kn_hook points to freed vnode.

Well, if that happens, then the vnode isn't properly clearing up the
knote before it gets reclaimed...  It is the vnode's responsibility to
make sure any knotes that are associated w/ it get cleaned up properly..

> The issue as I see it is that vnode lifecycle is detached from the knote
> lifecycle.  Might be, only the second patch, which acquires a hold reference
> on the vnode for each knote, is really needed.  But before going into any
> conclusions, I want to see the testing results.

The vnode lifecycle can't/shouldn't be detached from the knote lifecycle
since the knote contains a pointer to the vnode...  There is the function
knlist_clear that can be used to clean up knotes when the object goes
away..

I was looking at the code, is there a good reason why you do
VI_LOCK/VI_UNLOCK to protect the knote fields instead of getting it in
the vfs_knllock/vfs_knlunlock functions?  Because kq code will modify
the knote fields w/ only running the vfs_knllock/vfs_knlunlock functions,
so either the VI_LOCK/VI_UNLOCK are unnecessary, or should be moved to
vfs_knllock/vfs_knlunlock...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 9.2-RC3 - suspend/resume causes slow system performance

[Mike Harding]

My slowdown manifests as extremely slow disk access, even with low CPU.
This happens even
if CPU scaling is disabled, or if I am remotely accessing the system, with
no X.


On Wed, Sep 25, 2013 at 8:01 AM, Bengt Ahlgren  wrote:

> Now having some experience with my "new" TP X201 and Intel/KMS graphics,
> I also ran into severe Xorg perfomance issues, but it was _not_
> connected to suspend/resume, because it persisted after a clean reboot.
>
> I plugged in a projector to the VGA port, and used xrandr.  The Xorg
> server seemed to come to a halt, in practice unusable.  After the fact I
> saw in the log file that there were tons of these messages:
>
> [   136.238] (II) intel(0): EDID vendor "IFS", prod id 4354
> [   136.238] (II) intel(0): Using hsync ranges from config file
> [   136.238] (II) intel(0): Using vrefresh ranges from config file
> [   136.238] (II) intel(0): Printing DDC gathered Modelines:
> [   136.238] (II) intel(0): Modeline "1280x800"x0.0   83.40  1280 1344
> 1480 1680  800 801 804 828 -hsync +vsync (49.6 kHz eP)
> [   136.238] (II) intel(0): Modeline "800x600"x0.0   40.00  800 840 968
> 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
> [   136.238] (II) intel(0): Modeline "800x600"x0.0   36.00  800 824 896
> 1024  600 601 603 625 +hsync +vsync (35.2 kHz e)
> [   136.238] (II) intel(0): Modeline "640x480"x0.0   31.50  640 656 720
> 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
> [   136.238] (II) intel(0): Modeline "640x480"x0.0   31.50  640 664 704
> 832  480 489 492 520 -hsync -vsync (37.9 kHz e)
> [   136.238] (II) intel(0): Modeline "640x480"x0.0   30.24  640 704 768
> 864  480 483 486 525 -hsync -vsync (35.0 kHz e)
> [   136.238] (II) intel(0): Modeline "640x480"x0.0   25.18  640 656 752
> 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
> [   136.238] (II) intel(0): Modeline "720x400"x0.0   28.32  720 738 846
> 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
> [   136.238] (II) intel(0): Modeline "1280x1024"x0.0  135.00  1280 1296
> 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
> [   136.238] (II) intel(0): Modeline "1024x768"x0.0   78.75  1024 1040
> 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
> [   136.238] (II) intel(0): Modeline "1024x768"x0.0   75.00  1024 1048
> 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
> [   136.238] (II) intel(0): Modeline "1024x768"x0.0   65.00  1024 1048
> 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
> [   136.238] (II) intel(0): Modeline "832x624"x0.0   57.28  832 864 928
> 1152  624 625 628 667 -hsync -vsync (49.7 kHz e)
> [   136.238] (II) intel(0): Modeline "800x600"x0.0   49.50  800 816 896
> 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
> [   136.238] (II) intel(0): Modeline "800x600"x0.0   50.00  800 856 976
> 1040  600 637 643 666 +hsync +vsync (48.1 kHz e)
> [   136.238] (II) intel(0): Modeline "1152x864"x0.0  108.00  1152 1216
> 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
> [   136.238] (II) intel(0): Modeline "1280x720"x60.0   74.48  1280 1336
> 1472 1664  720 721 724 746 -hsync +vsync (44.8 kHz e)
> [   136.238] (II) intel(0): Modeline "1280x960"x0.0  108.00  1280 1376
> 1488 1800  960 961 964 1000 +hsync +vsync (60.0 kHz e)
> [   136.238] (II) intel(0): Modeline "1280x1024"x0.0  108.00  1280 1328
> 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
> [   136.238] (II) intel(0): Modeline "1366x768"x59.8   84.75  1366 1431
> 1567 1776  768 771 781 798 -hsync +vsync (47.7 kHz e)
> [   136.238] (II) intel(0): Modeline "1440x900"x0.0  106.50  1440 1520
> 1672 1904  900 903 909 934 -hsync +vsync (55.9 kHz e)
> [   136.238] (II) intel(0): Modeline "1400x1050"x0.0  121.75  1400 1488
> 1632 1864  1050 1053 1057 1089 -hsync +vsync (65.3 kHz e)
> [   136.238] (II) intel(0): Modeline "1600x1200"x0.0  162.00  1600 1664
> 1856 2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz e)
> [   136.238] (II) intel(0): Modeline "1680x1050"x0.0  146.25  1680 1784
> 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz e)
>
> That is, the Xorg server constantly queried the display device for its
> capabilities (perhaps on behalf of some client - I run KDE, so you never
> know what it tries to do...).
>
> This seems to be a somewhat known issue:
>
>
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/310857
>
> Is this something different, or is this a variant of the slowdown others
> are seeing?
>
> Bengt
>
> Adrian Chadd  writes:
>
> > .. anything happening?
> >
> >
> > -adrian
> >
> >
> > On 2 September 2013 07:29, Adrian Chadd  wrote:
> >
> >>
> >> On 2 September 2013 07:25, Mike Harding  wrote:
> >>
> >>> It's detailed in the ticket,  see
> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for
> >>> 'reverted'.
> >>>
> >>>
> >> Ok. You and avg@ are digging into it deeper, so I'll leave it be for
> now.
> >> I'll retest this on my test laptops when I'm back home.
> >>
> >>
> >>
> >> -adrian
>
___
freebsd-stable@freebsd.org 

Re: 9.2-RC3 - suspend/resume causes slow system performance

[Bengt Ahlgren]

Now having some experience with my "new" TP X201 and Intel/KMS graphics,
I also ran into severe Xorg perfomance issues, but it was _not_
connected to suspend/resume, because it persisted after a clean reboot.

I plugged in a projector to the VGA port, and used xrandr.  The Xorg
server seemed to come to a halt, in practice unusable.  After the fact I
saw in the log file that there were tons of these messages:

[   136.238] (II) intel(0): EDID vendor "IFS", prod id 4354
[   136.238] (II) intel(0): Using hsync ranges from config file
[   136.238] (II) intel(0): Using vrefresh ranges from config file
[   136.238] (II) intel(0): Printing DDC gathered Modelines:
[   136.238] (II) intel(0): Modeline "1280x800"x0.0   83.40  1280 1344 1480 
1680  800 801 804 828 -hsync +vsync (49.6 kHz eP)
[   136.238] (II) intel(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  
600 601 605 628 +hsync +vsync (37.9 kHz e)
[   136.238] (II) intel(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  
600 601 603 625 +hsync +vsync (35.2 kHz e)
[   136.238] (II) intel(0): Modeline "640x480"x0.0   31.50  640 656 720 840  
480 481 484 500 -hsync -vsync (37.5 kHz e)
[   136.238] (II) intel(0): Modeline "640x480"x0.0   31.50  640 664 704 832  
480 489 492 520 -hsync -vsync (37.9 kHz e)
[   136.238] (II) intel(0): Modeline "640x480"x0.0   30.24  640 704 768 864  
480 483 486 525 -hsync -vsync (35.0 kHz e)
[   136.238] (II) intel(0): Modeline "640x480"x0.0   25.18  640 656 752 800  
480 490 492 525 -hsync -vsync (31.5 kHz e)
[   136.238] (II) intel(0): Modeline "720x400"x0.0   28.32  720 738 846 900  
400 412 414 449 -hsync +vsync (31.5 kHz e)
[   136.238] (II) intel(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 
1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[   136.238] (II) intel(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 
1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[   136.238] (II) intel(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 
1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
[   136.238] (II) intel(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 
1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[   136.238] (II) intel(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  
624 625 628 667 -hsync -vsync (49.7 kHz e)
[   136.238] (II) intel(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  
600 601 604 625 +hsync +vsync (46.9 kHz e)
[   136.238] (II) intel(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  
600 637 643 666 +hsync +vsync (48.1 kHz e)
[   136.238] (II) intel(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 
1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[   136.238] (II) intel(0): Modeline "1280x720"x60.0   74.48  1280 1336 1472 
1664  720 721 724 746 -hsync +vsync (44.8 kHz e)
[   136.238] (II) intel(0): Modeline "1280x960"x0.0  108.00  1280 1376 1488 
1800  960 961 964 1000 +hsync +vsync (60.0 kHz e)
[   136.238] (II) intel(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 
1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[   136.238] (II) intel(0): Modeline "1366x768"x59.8   84.75  1366 1431 1567 
1776  768 771 781 798 -hsync +vsync (47.7 kHz e)
[   136.238] (II) intel(0): Modeline "1440x900"x0.0  106.50  1440 1520 1672 
1904  900 903 909 934 -hsync +vsync (55.9 kHz e)
[   136.238] (II) intel(0): Modeline "1400x1050"x0.0  121.75  1400 1488 1632 
1864  1050 1053 1057 1089 -hsync +vsync (65.3 kHz e)
[   136.238] (II) intel(0): Modeline "1600x1200"x0.0  162.00  1600 1664 1856 
2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz e)
[   136.238] (II) intel(0): Modeline "1680x1050"x0.0  146.25  1680 1784 1960 
2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz e)

That is, the Xorg server constantly queried the display device for its
capabilities (perhaps on behalf of some client - I run KDE, so you never
know what it tries to do...).

This seems to be a somewhat known issue:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/310857

Is this something different, or is this a variant of the slowdown others
are seeing?

Bengt

Adrian Chadd  writes:

> .. anything happening?
>
>
> -adrian
>
>
> On 2 September 2013 07:29, Adrian Chadd  wrote:
>
>>
>> On 2 September 2013 07:25, Mike Harding  wrote:
>>
>>> It's detailed in the ticket,  see
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for
>>> 'reverted'.
>>>
>>>
>> Ok. You and avg@ are digging into it deeper, so I'll leave it be for now.
>> I'll retest this on my test laptops when I'm back home.
>>
>>
>>
>> -adrian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

strsvis breakage when upgrading to from 9.1 to 9-STABLE

[Ivan Voras]

Hello,

I've sent a similar query before, but didn't receive any answers.

When upgrading from 9.1 to 9-STABLE, the buildworld fails with:

===> usr.bin/xinstall (all)
cc -O2 -pipe  -I/usr/src/usr.bin/xinstall/../../contrib/mtree
-I/usr/src/usr.bin/xinstall/../../lib/libnetbsd
-I/usr/src/usr.bin/xinstall/../../lib/libmd -std=gnu99 -fstack-protector
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/usr/src/usr.bin/xinstall/xinstall.c
cc -O2 -pipe  -I/usr/src/usr.bin/xinstall/../../contrib/mtree
-I/usr/src/usr.bin/xinstall/../../lib/libnetbsd
-I/usr/src/usr.bin/xinstall/../../lib/libmd -std=gnu99 -fstack-protector
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/usr/src/usr.bin/xinstall/../../contrib/mtree/getid.c
cc1: warnings being treated as errors
/usr/src/usr.bin/xinstall/xinstall.c: In function 'metadata_log':
/usr/src/usr.bin/xinstall/xinstall.c:1331: warning: implicit declaration
of function 'strsvis'
/usr/src/usr.bin/xinstall/xinstall.c:1331: warning: nested extern
declaration of 'strsvis'

Digging around, it looks like strsvis is in the 9-STABLE sources but not
in the installed system's (9.1) sources. I assume the build process is
pulling in system headers and libraries, but that seems wrong. Isn't the
build process supposed to pull in only sources from /usr/src and
libraries which are freshly built instead of the system ones?

What would be the workaround for the above problem?



signature.asc
Description: OpenPGP digital signature

Re: FreeBSD 9.1 ix driver vlan problem

[Daniel Kalchev]

On 25.09.2013, at 02:16, Rumen Telbizov  wrote:

> 
> 
> Example:
> ifconfig vlan200 create  # this is OK
> ifconfig vlan200 inet 1.2.3.1/30  vlan 200 vlandev ix1 description DEBUG #
> this second line makes the rest of the vlans freeze for 6-7 seconds
> 
> On the switch side (Juniper) the physical interface flaps. There's nothing
> in logs/dmesg.
> 

Might be, you have spanning tree enabled on the switch port and when the 
interface "flaps" it needs time to converge. Disable spanning tree on the port 
and the reset will be very short.

Daniel

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Possible kqueue related issue on STABLE/RC.

[Konstantin Belousov]

On Wed, Sep 25, 2013 at 09:58:05AM +0200, Patrick Lamaiziere wrote:
> Le Wed, 25 Sep 2013 00:21:27 +0300,
> Konstantin Belousov  a ?crit :
> 
> Hello,
> 
> > On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
> > > I'd like to understand why you think protecting these functions w/
> > > the _DETACHED check is correct...  In kern_event.c, all calls to
> > > f_detach are followed by knote_drop which will ensure that the knote
> > > is removed and free, so no more f_event calls will be called on that
> > > knote..
> > 
> > My current belief is that what happens is a glitch in the
> > kqueue_register(). After a new knote is created and attached, the kq
> > lock is dropped and then f_event() is called. If the vnode is
> > reclaimed or possible freed meantime, f_event() seems to dereference
> > freed memory, since kn_hook points to freed vnode.
> > 
> > The issue as I see it is that vnode lifecycle is detached from the
> > knote lifecycle.  Might be, only the second patch, which acquires a
> > hold reference on the vnode for each knote, is really needed.  But
> > before going into any conclusions, I want to see the testing results.
> 
> Testing looks good with your latest patch. I was able to run a complete
> poudriere bulk (870 packages). I'm running another bulk to see.
> 
> If you have other patches to test just ask, I have not updated my
> packages because there was a change to make gvfsd to ignore some
> poudriere activity. So I guess it will be harder to see this
> problem.

Very good, thank you.

Could you, please, test with the only patch
http://people.freebsd.org/~kib/misc/vnode_filter.1.patch
applied ?  I wonder would it be enough.


pgp7_QMOxJKl9.pgp
Description: PGP signature

Re: Possible kqueue related issue on STABLE/RC.

[Patrick Lamaiziere]

Le Wed, 25 Sep 2013 00:21:27 +0300,
Konstantin Belousov  a écrit :

Hello,

> On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
> > I'd like to understand why you think protecting these functions w/
> > the _DETACHED check is correct...  In kern_event.c, all calls to
> > f_detach are followed by knote_drop which will ensure that the knote
> > is removed and free, so no more f_event calls will be called on that
> > knote..
> 
> My current belief is that what happens is a glitch in the
> kqueue_register(). After a new knote is created and attached, the kq
> lock is dropped and then f_event() is called. If the vnode is
> reclaimed or possible freed meantime, f_event() seems to dereference
> freed memory, since kn_hook points to freed vnode.
> 
> The issue as I see it is that vnode lifecycle is detached from the
> knote lifecycle.  Might be, only the second patch, which acquires a
> hold reference on the vnode for each knote, is really needed.  But
> before going into any conclusions, I want to see the testing results.

Testing looks good with your latest patch. I was able to run a complete
poudriere bulk (870 packages). I'm running another bulk to see.

If you have other patches to test just ask, I have not updated my
packages because there was a change to make gvfsd to ignore some
poudriere activity. So I guess it will be harder to see this
problem.

Many thanks Konstantin,
Regards
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.1 ix driver vlan problem

[Jack Vogel]

I will look into this.

Jack



On Tue, Sep 24, 2013 at 5:16 PM, Rumen Telbizov  wrote:

> Hello Jack, list,
>
> I've been dealing with a nagging problem for a day now and decided to ask a
> quick question here.
>
> Basically I am building a brand new FreeBSD 9.1-RELEASE router which has a
> dual port fiber NIC (X520-SR2 10GbE Dual-Port Server Adapter (82599ES)
> 10GBASE-SR - LC). The network card is recognized fine by the ix driver and
> overall works fine.
>
> The issue is when I start adding vlans to this card. It seems like every
> time I add a brand new vlan it "freezes" all the rest of the vlans already
> configured on that one physical interface. I loose ping between my locally
> connected peers.
>
> Example:
> ifconfig vlan200 create  # this is OK
> ifconfig vlan200 inet 1.2.3.1/30  vlan 200 vlandev ix1 description DEBUG #
> this second line makes the rest of the vlans freeze for 6-7 seconds
>
> On the switch side (Juniper) the physical interface flaps. There's nothing
> in logs/dmesg.
>
> If I configure the above vlan on an em0 interface - things are just smooth.
>
> I read some similar complaints that have surfaced in the past:
>  * http://readlist.com/lists/freebsd.org/freebsd-net/5/26378.html
>  * http://marc.info/?l=freebsd-net&m=130929760904438
>
> Any idea what might be the problem? Any improvements in 9.2-RC4 in this
> regards?
>
> Thank you in advance,
>
> --
> Rumen Telbizov
> Unix Systems Administrator 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"