FreeBSD 13 Beta2 very slow boot

[dan_partelly]

Hey.

Was the 13 beta 2 AMD64 image compiled  and released with debug settings 
active ? EFI portion of the boot is an order of magnitude at least 
slower than Beta 1.


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

Enable veriexec for 13 Beta 1

[dan_partelly]

Hey guys,

What are the config knobs for enabling the veriexec driver and veriexec 
mac modules for testing and playing with this new subystem ? User mode 
knob for user mode tool and lib is documented in man src.conf Thanks !

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

Re: Devd / devmatch(8) -- netif race 12-RC1

[dan_partelly]

We're missing a fair bit of information to come to any conclusion yet.


Cy, did you used  it when loading the wifi drivers automatically with 
devmatcher ?  Cause if you run GENERIC, chances are that you will not 
see any weird behavior. Most wifi drivers are compiled in kernel in this 
case.  Meaning you will have no issues. The exception are bwi/bwn 
Broadcom drivers, those are not compiled in kernel. if you compile your 
kernel without the wifi drivers you use, and if said drivers already 
changed to support to be loaded automatically by devmatcher, you can 
research the behavior.


And yes, I used too it for years too with wifi drivers compiled in 
kernel or statically loaded before netif runs. And it works, save for 
some PCI wired cards whose drivers where not able to sense correctly 
media presence


net.wlan.devices contains the expected value for the hardware 
configuration, and correct drivers and firmware loaded , bwi0.

This is a stock installation with GENERIC and no modifications

What happens is that lagg0 is created and it’s initialization  takes 
place way before devmatcher loads the driver for wifi card and it’s  
firmware and  wlan0 is created. Meaning, slave laggport interface (wlan0 
) does not exist at the time the initialization is run. Meaning that it 
will fail.


Dan

În 2018-11-22 17:25, Cy Schubert a scris:

In message <798c848d-5f32-4bf9-87e0-add4f9b74...@rdsor.ro>, Dan
Partelly writes
:
wireless lagg initialization is broken in this scenario, all-right. 
The init/
rc system as it is now can’t cope easily with a modern asynchronous 
initial
ization sequence. Sure you could probably find an order which works, 
only to
find yourself in trouble next time you want  add some modern 
functionality  .

 It shows it’s age

@Warner

Could you tell me please if devmatcher supports taking over a PCI 
device whic
h is attached by a generic driver already ? vga attaching modern GPUs 
comes t

o mind .

Dan


We're missing a fair bit of information to come to any conclusion yet.
I've been using lagg with ath + rl and iwn + bge since FreeBSD 8,
currently on 13, with zero issues or problems on either of them over
the many years I've used this configuration.

Can you provide output of sysctl net.wlan.devices, please? Also the
relevant bits of rc.conf (with PI redacted of course), and any
modifications to devfs.conf. dmesg output and anything relevant in
messages might also be helpful.


--
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.





> On Nov 20, 2018, at 15:26, Bjoern A. Zeeb 
wrote:
>
> On 20 Nov 2018, at 8:17, dan_parte...@rdsor.ro wrote:
>
 No, that's not what's happening. wlan0 isn't racing anything, because it
's no longer listed in ifconfig
>>
>>
>> But when is created lagg0 ? Acording rc output on screen , creation of clo
ned interface lagg0 takes place before wlan0 is created. Then this  
means SIO
CLAGPORT will fail with Invalid argument.  Also lagg0 is started at 
netif tim

e as far as I know.
>> Firmware for the wireless card is loaded later, and only even later wlan0
is created. So the way I see it, lagg0 cannot have a wlan0 port until 
firmwar
e for the card is loaded and wlan0 is created, which takes place way 
after th

e system attempts to configure lagg0  ? Am I missing something ?
>
> lagg might be a problem.
>
>
> While we are on the topic: I also noticed on a fixed 10G card that the netw
ork startup it went through strangely wasn’t the same as it was when 
the dr
iver was loaded and service netif start was called again.  I have not 
had tim

e to debug that any further.
>
>
>> Also, can you please tell me what happens that devmatch tries to load  uhi
dd multiple times ?
>
> That’s probably similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi
?id=232782 ?

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



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

Re: Devd / devmatch(8) -- netif race 12-RC1

[dan_partelly]

No, that's not what's happening. wlan0 isn't racing anything, because 
it's no longer listed in ifconfig



But when is created lagg0 ? Acording rc output on screen , creation of 
cloned interface lagg0 takes place before wlan0 is created. Then this  
means SIOCLAGPORT will fail with Invalid argument.  Also lagg0 is 
started at netif time as far as I know.
 Firmware for the wireless card is loaded later, and only even later 
wlan0 is created. So the way I see it, lagg0 cannot have a wlan0 port 
until firmware for the card is loaded and wlan0 is created, which takes 
place way after the system attempts to configure lagg0  ? Am I missing 
something ?


Also, can you please tell me what happens that devmatch tries to load  
uhidd multiple times ?


Dan

În 2018-11-20 06:38, Warner Losh a scris:

On Mon, Nov 19, 2018 at 7:48 PM Dan Partelly 
wrote:


Hello,

Today I tried a simple wireless failover on a machine  running
free-bsd. After reboot the system cannot complete the initialization
sequence OK with devmatcher.
The devd/devmatch(8) combo correctly identified the wireless card
and loaded required drivers and firmware. rcorder(8) reports  that
devd(8) runs after netif. As far as I gather, devd (8) runs
devmatch(8) on nomatch class events. This results in the situation
in which the interfaces are created before “plug and play”
initialization of the wireless device is complete (no driver no
firmware yet ) , wlan0 creation is impossible and so on and so
forth.


No, that's not what's happening. wlan0 isn't racing anything, because
it's no longer listed in ifconfig.


More so, I believe the runs of devmatch(8) are async in this
scenario, so even if you moved devd(8) before netif service, this
would not solve the issue, there will be race conditions.  I know
this can be solved by loading the drivers manually, but still rising
some issue is in order:


Network configuration happens asynchronously. devmatch gets run in
response to NOMATCH events which then causes the driver to load which
then causes the pccard_ether script to run which causes the device to
be configured. At least that's how it's supposed to work.


1) Why does devd(8) service runs after netif ? I believe it should
run before netif service, probably after kld service. Is there
anything which prevents changing this order ?


Because it doesn't matter? And because if devd is run too eary, too
few services are available. Getting the ordering right was... a
somewhat tricky and frustrating experience when I first committed
devd.


2.) In the scenario in which devd(8) is started before netif, what
can be done to ensure that a barier exists such that an arbitrary
devmatch(8) run is guaranteed to finish loading required drivers
before netif ? Ignore this if Im wrong about asyc nature of
devmatch(8) run.


Nothing. No such barrier is necessary. It should all happen
asynchronously. Maybe there's a config problem?


3 In what state is devmatcher now ? A lot of modules seems to be
loaded ok, but some do not yet. coretemp(4) hwpmc(4) , intel serie 9
smbus driver seems not.


All of USB is done, part of PCI is done, all of the really old PC Card
(since it was easy), parts of FDT for embedded and parts of ACPI are
done.

The drivers you've called out I think are PCI drivers that haven't
been updated. They should all be in GENERIC, but none are in MINIMAL
or perhaps a custom kernel.

coretemp is a CPU device, and so I'm not sure we have the right PNP
information for the CPU bus for it to even load.

Warner

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

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

This was all it was asked. Thanks.

> Im saying that feedback has been heard and understood and providing more
> now while things are in flux to try to address those issues is not
likely
> to be fruitful.
> Warner
> 
> Links:
> --
> [1] mailto:dan_parte...@rdsor.ro
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

It's lack of communication.

> *This* is the reason that *this* and similar topics become so heated;

> People who are part of a "community", such as FreeBSD. Want to feel
> they are part of the "big picture", and immediately feel resentment,

It is in fact much more than that. Surely there are  such psycho-social
effects as you describe, after all we humans are subject to hundred os
socio-psycological biases. But there is a much more practical and mundane
issue as well:
People who use this operating system in their operations have a great
stake in it. Such changes affect operations. I welcome change, but at the
same time I try to ensure that change goes smoothly. Investing in BSDs by
using them
in our operation is not a whim, or a decision made drunk under a bridge.
It costs us money, time , investment in educating other people to
administer those OSEs, continuous education  to keep up with change. More
than all this, it
costs us business reputation when we decide to build an infrastructure for
a client on BSDs, and something goes wrong. And I want to keep my customers
happy and so far the BSDs delivered this. 

> when they find they were left out of "big" decisions, like pkg(8).

IMO, Its not a problem to be left out of decisions. First, because they
are not our decisions to take, and second because I believe decisions are
better to be made by small group of persons.  What is a problem is the fact
that when you 
discuss those projects and voice your opinions, some label you "anti
progress", some " peasant storming a (lord's) castle (with or without a
pitchfork,cant remember :P) , others feel that you dont appreciate them and
their time, and then they retreat somewhere. You can invalidate the
decision made by said group by stoping using the product. Im sure none
would care in the unlikely even that I would  stop using FreeBSD, but I
think they cared when Yahoo stopped using it. Or if they did not, they 
should have cared :P



> People who are part of a "community", such as FreeBSD. Want to feel
> they are part of the "big picture", and immediately feel resentment,
> when they find they were left out of "big" decisions, like pkg(8).
> While the conversation may well have been heated. It would *not*
> have meet *quite* as much adamant, persistent resistance. Because
> it (pkg) would have been molded into something from the culmination
> of the "community'" input.
> 
> This is only from 50 years in the service industry, and the
> thousands of mailing lists I've been on, talking here.
> 
> --Chris
> 
>> 
>> -- 
>> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
>> p...@freebsd.org | TCP/IP since RFC 956
>> FreeBSD committer   | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by
>> incompetence.
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "freebsd-current-unsubscr...@freebsd.org"
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> 
> Not taking a side on this discussion, yet… but the first thing that

I do not believe there are sides to take, because I am absolutely positive
everybody in this thread wants only whats better for FreeBSD, so there is
only one side. It is an aspect which in the heat of emotions some people
seem to forget.

>> The benefits might be worth it in the long run.

The benefits are great and they are immediately available upon release of
a packaged base. I am all for it . Yet there issue, such as the UI which
doesn't handle well big numbers of packages, mechanism issues and
convention issues which where raised in another thread and went unanswered
by devs so far. 

Personally my greatest fear is that what happen to VIMAGE wouldn't happen
with this great feature. Namely, that it goes in effect with a "good
enough" implementation (which may well be a great success for some uses)
and then we have to work with the "good enough" implementation for half a
decade before it is made bullet proof and orthogonal. Or that UI issues are
never solved, claiming that they are "largely cosmetic" anyway. I wouldn't
mind waiting 2 point releases for example
to become that way, but look, for VIMAGE takes what ... 6 years ? 

(Nota bene: I do not contest that VIMAGE is great. )

Pople raised valid concerns, devs imvolved in the project seen them, yet
those who spearhead the base pkg project did not found appropriate to make
a statement to quell ppl fears regarding their commitment to see to all the
issues in a pre-determined time frame. I.E a commitment to make it bullet
proof by 11.1 as example. Some felt threatened and unappreciated, which is
a problem. Both for them and for us, the user. Because the users of this OS
are not only the companies who employ the developers, there are thousand of
people scattered through the world, ppl who have a great stake invested in
this operating system, by the simple fact that they use it everywhere. 

Another small issue, is in general the politics of the FreeBSD dev team
regarding bug fixes. I personally would be glad to see more commitment from
the dev team regarding bug fixes. It is kinda disappointing to see known
bugs 
going on and on for years, "good enough" susbsytems having the same fate,
and so on. 

I beleive the team per-ansamble should make a more solid commitment to fix
outstanding issues, and try to outline a policy regarding bugs and
implementations which lack orthogonality or are only partially completed
(even if this partially means 95% ).

 

> occurred to me is that such way of packaging is traditional for the
Linux
> “distributions”. I could imagine people worrying at subconscious level
that
> FreeBSD is going the Linux way… and that if they wanted such a model,
they
> would be using Linux instead. Today, people have more choice in
packaging —
> but if FreeBSD goes the Linux way, someone else will fill the void — so
no
> worries in general.
> 
> I can see the support nightmare that a packaged base would bring, but as
> always — this is not enough to judge it. The benefits might be worth it
in
> the long run.
> 
> I was a long time user of BSD/OS and then switched to FreeBSD when that
OS
> was killed. In BSD/OS everything was monolithic. It was rock stable.
Very
> dependable and very easy to support. My first few years with FreeBSD
were
> spent to get used that the OS was not just one piece, but you could end
up
> with different installs.. A bit more support efforts. Not that I am
> complaining :)
> 
> As long as packaged base is not mandatory, it is fine by me.
> 
> Daniel
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

This is one of the issue I perceive with using scripts/ intermediate
programs 
as a  glue, a problem which does not exist when the daemons are integrated

tighter. You basically give up all the power which arises from
inter-operating 
daemons give to the system. 

It is also the main problem FreeBSD's rc system presents. Because all is a

scaffolding of shell scripts, it basically gives you 0 of the power modern

service management offer. Most important are service life cycle
management,
restart policies, delegated administration  and fault reporting. The only
thing 
you gain is easy  debugability (no small boon)but it is easily outweighted
by all 
other advantages of a modern service manager. 

> 
> Well, even if we went this route, this wouldn't quite work, because
> the automountd daemon actually doesn't need those notifications.
> It's the "-media" map that does.  Other parts of autofs don't have
> any special code for media handling.

About shell scripts in general as a glue:

Yes, they are easily debuggable and customized. Yet I believe that all
that 
power should be hidden,and it should be unnecessary to tap into it for 95%
of 
administrative needs.   It is my perception that less and less people are 
interested in exploring the countless ranges of customization such
scaffolding 
of scripts offer. People are interested in sane defaults, easy to specify
policies and fault reporting. Life is too short to explore myriad of 
customizations, unless you really have to. And most of the time, you dont
need 
to.

Thats not to say shell scripts dont have their place. They do. I use them 
too, both on  unixes and tcl scripts for adding fast functionality in
csico 
devices. But as a glue between essential operating system subsystems, it
is
my oppinion that we are 10 years too late in replacing them.


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

Re: devd limitations -- was [CFT] packaging the base system with pkg(8)

[dan_partelly]

>  Ideally, when the automounter daemon starts, it should
> connect to devd via an IPC channel and request notification of the
specific
> events that it wants

I was under the impression that devd.seqpacket.pipe accomplishes this.
Am I right in assuming that the issue is that devd forwards ALL events
to a client now, and the limitation is that we cannot specify a filter ?
Or there is something else more deep and fundamental ? I am planning to
use 
devd for a inhouse tool.

>> though hopefully will appearat some point in the 11.x series.

There are a lot of daemons IMO which would benefit from a tighter
integration
with devd, and abolishment of glue scripts or programs between devd and
clients
is desirable IMO. Fingers crossed.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> If these informations were more public I think there will be less 
> annoyed posts in mailinglist and more constructive critics / ideas / 
> patches.
> 

And there other issues arising from the lack of communication:

How exactly bugs / incomplete features are treated in FreeBSD ?  Many
times the public gets the impression that save for the show-stopper bugs,
or bugs which affect the employers of FreeBSD developers, 
they don't get too much priority. If any. 

I talked before about VIMAGE and the bugs surrounding it. Some of those
bugs  are  there for years. Yes VIMAGE was good enough, and as was told
before in this thread a success. I am not contesting that. Yet not even
today all those bugs and memory leaks are fixed.  Patches for some  bugs
floated around, some where collected some not, only god knows. I heard that
now for FreeBSD 11 the FreeBSD foundation forked some money to get it
done. I hope they will.

Another example is the autofs mounter. The prject was marked as complete
by FreeBSD foundation in 2014. Last I tried it to autmount removable
devices, it left directory after directory in the autofs managed directory.
This is known behavior. It also did not worked as it should ??? (show it
manage removable media correctly ) changing CD/DVD media disks. Presumably
In could have somehow manage it to work by making yet another scaffolding
of scripts as a questionable glue between devd and automounters.  That if
devd receives media change notifications. I dont know. If not I could patch
the kernel, yeah. But it is just much to simple to not bother at all and
use OSx. 

DRM drivers ? Done, but more or less in the same state by years. At least
not important in server space. 

outlining those issues should not make anyone feel criticized. Things are
what they are, maybe its better to think what are the root causes of issues
like those outlined before. Does the project lacks manpower ? If it does
maybe the developers should do something to attract and nurse more and more
potential people.  Are those issues you dont want to work on or you dont
have an agenda to  make them bug free and work orthogonal? No problem, make
a statement and
say .. we wont ever do this , or it will take 6 years ... or whatever.

It is not helpful to complain that people do not appreciate your hard
work, becuae ppl do. Also not helpful to complain about tones which should
be toned down by 2 orders of magnitude, peasants and castles.   
 It is also not helpful to complain that people oppose progress when you
are pointed some issues.It couldn't be further removed from truth, at least
in my case. But I think most ppl on this list want progress. At least this
is my impression.  Too much of Unix is badly stuck in the past.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> 
> "I've given your response all the consideration that I think it's due.
> Please have
> a nice day."


Thank you, Warner. Knowing you did, brings warm feelings in my hearth.
Please have a nice day. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

On Wed, 20 Apr 2016 04:07:11 +, Glen Barber <g...@freebsd.org> wrote:
> On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote:
>> 
>> > 
>> > Sadly the tenor and tone of the discussion isn’t one where progress
is
>> > made. The tone has been a bit toxic and demanding, which grinds
people
>> into
>> > dust, rather than motivating them to fix things. You might call it a
>> > discussion, but it reads to me more as a bunch of angry villagers
>> storming
>> > the castle. No good can come from that. Tone down the outrage by a
>> factor
>> > of 100 and try to have the conversation again.
>> > 
>> 
>> I'm frankly perplexed by this statement. Its seldom I perceived so much

>> sorrow and bitterness in 6 lines. There is no castle Warner, unless you
>> want one to exist, one where you can isolate yourself from the
>> indentured
>> peasants and anything they say. Beyond your thick walls you'll be well
>> served,
>> every idea outside your wals will be toned down by a factor of 100 by
the
>> time
>> it reaches  the lord, becoming total agreement with anything the lord
>> thinks. 
>> 
>> I cant believe I wrote this shit. But then again, I cant believe you
just
>> wrote
>> what you did.
>> 
> 
> And it's responses like this that are severely demotivating.

Such statements, such answers. But Im done with this. It degenerates
in emotional outbursts, much to the shame of all parts involved.

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

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> 
> Sadly the tenor and tone of the discussion isn’t one where progress is
> made. The tone has been a bit toxic and demanding, which grinds people
into
> dust, rather than motivating them to fix things. You might call it a
> discussion, but it reads to me more as a bunch of angry villagers
storming
> the castle. No good can come from that. Tone down the outrage by a
factor
> of 100 and try to have the conversation again.
> 

I'm frankly perplexed by this statement. Its seldom I perceived so much 
sorrow and bitterness in 6 lines. There is no castle Warner, unless you
want one to exist, one where you can isolate yourself from the indentured 
peasants and anything they say. Beyond your thick walls you'll be well
served,
every idea outside your wals will be toned down by a factor of 100 by the
time
it reaches  the lord, becoming total agreement with anything the lord
thinks. 

I cant believe I wrote this shit. But then again, I cant believe you just
wrote
what you did.



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

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

On Tue, 19 Apr 2016 20:09:30 +, "Poul-Henning Kamp"
 wrote:
> As far as I know, nobody is taking the source code or the Makefiles
> away, so if somebody doesn't like the system being distributed with
> pkg, they can very well roll their own.
> 
> It's nice to see the level of enthusiasm the FreeBSD project can
> muster, I just wish it wasn't always enthusiasm for stopping progress.

Your statement, at least as pertaining to this particular exchange, is
unfair by any criteria.
I dont think anybody in their right mind would oppose the base packaging
project, all I seen 
where concerns regarding the pkg maturity, and how it handles the sheer
number of resulting packages. 
which, if you think a bit, are legitimate concerns, whatever you agree
with this stance or not.

Yes, it is high time for progress. It is high time that FreeBSD foundation
uses a more sizable chunk
of the donations it receives to pay for projects bringing progress in
FreeBSD.Maybe it is also high time
that companies which make millions using BSD OSes (like Juniper) would
give something substantial back. 
Speaking of progress, somebody should take a look at the autoexec.bat
system called rc, and pay (foundation money)
to have it rewritten in a modern form , which allows service sane service
management and a modern fault reporting
interface. Have the FreeBSD foundation pay to port those from Solaris. 
Also, while here, take a good look at the base system , and use same
foundation money to ensure you expose 
in libraries all critical interfaces to the OS. Next, get a decent IPC
system (there is already code there for this
in the form of Mach ports in NextBSD. Yeah, FreeBSD needs a better way to
do IPC that posix and plain unix domain sockets.


Code is speaking lauder than words, so please, use the opportunity created
by Hubbard and his NextBSD to get a much needed
IPC system in FreeBSD. To be fair, it is needed for progress. 

Lastly, look in a more timely manner to the summer of code projects which
might have produced some useful code. 
Year after year you hear about new GsoC projects, then nothing. I find it
hard to bleive that none of those actually 
produced any useful code.

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

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> 
> Look, take a look at history and the Linux kernel threads story and its 
> impact on FreeBSD.  If you'd like I can talk about it.
> 

Please, yes, I would love to hear about it.

> -Alfred
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> 
> What should not happen is that this incremental step forward be blocked 
> by those unwilling to hash out the next steps.
> 
> -Alfred
> 
> 

While incremental steps forward are great, how do you avoid situations
like VNET, where a "good enough" enough implementation, usable in some 
scenarios lingered for years in kernel, but to this day it suffers from
leaks and bugs. Once you go down the path of enabling it in this state, 
chances are that it will stay that way for more than half a decade. 





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

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

I dont know if you missed the point of my message on purpose or not.

I never pretended that you can't extract that information. I maintain that
having sane defaults would empower me to almost never care about aliases,
scripts
pipes, filter , regular expressions and what not. It is great that all
this power
is at my fingertips, in case something goes awfully wrong , not so great
when Im forced
to use it. 

And I really don't see how this helps anyway, since number of leafs will 
increase anyway with package base. 

Let me reiterate, perhaps clearer this time:

It is my opinion that sane defaults beat ANY script, obscure command line
arguments, 
alias, pipe, filter, helper program. 



> 
> Don't use "pkg info" then. Use "pkg leaf":
> 



 
> And to everyone complaining about the number of packages: How many of
> you have actually used the packaged base?

This question is irrelevant. 

1.First of all, many people consider packaging base a great
accomplishment, 
yet maybe not ready for prime-time, given the current way pkg handles this

information. I personally love the idea, with the caveats above. 

2. The issue is present with all meta-packages in general. The base
packaging
only exacerbate an existing issue with the sheer number of packages it
presents. 


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

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

For what is worth, I agree with Julian Elischer. I do not 
want to see hundreds of packages over tenths of screen pages. 

Computers are supposed to make our life simpler. Human time is
very expensive. CPU time, almost free. And this include that I really 
shouldn't have to think for usual work of any grep, sed , regexpes, 
pkg --leafs whatever. The default high level output of a tool like pkg
should 
be as terse as possible. You guys seen the "Add remove programs"
 in Windows control panel ? Thats sane. Even now the default output  
of pkg borders insane, when you have many packages installed. 99% of my
time
I dont really care about lib-rtyum546.78.9. I care only less than 1% of my
time when something 
goes wrong. 

The program | filter pipeline of Unix is very powerful. Whats more
powerful is 
SANE DEFAULTS to make filters completely unnecessary. The open source Unix
world has a lot
to learn from Cupertino and Redmond. Keep things simple please. DO not
pollute my screens
with unnecessary information. When Ill want that info, Ill ask for it with
a command line flag,
then maybe filter it if necessary. 


On Tue, 19 Apr 2016 15:44:41 +0800, Julian Elischer 
wrote:
> On 19/04/2016 5:29 AM, Alfred Perlstein wrote:
>> Guys please stop arguing about the number of packages.  The high 
>> granularity is VERY useful!
>>
> it's going to make us a laughing stock
> "look FreeBSD just split into 1.43 million packages" (effectively the 
> same number.. it's bigger than 10)
> 
> 
>> Managing large groups of small packages is much easier than just 
>> having large packages.
> err, Alfred, what planet do you live on? when they get out of sync it 
> becomes a nightmare.
> If you also had a packaging system that was smart enough to manage a 
> hierarchy of packages then "maybe"..
> 
>>
>> All this can be done by meta-packages which depend on larger package 
>> groups.
> Currently Metapackage is a way to make 10 packages look like 11 
> packages.  The framework needs to understand to hide the 10 internal 
> packages if they are part of a metapackage.
>>
>> Later pkg can be augmented to "remove packages not explicitly 
>> installed" which would remove leaf packages.
>>
>> Example: you installed "base-debug" which pulls in let's say 50 
>> small packages, later you want all of those removed, you can do 
>> something like:  "pkg delete --leafs base-debug" which should delete 
>> "base-debug" and any dangling packages it pulled in not required by 
>> other pkgs.
>>
>> Huge thanks to the team that implemented this!
> 
> I'm sure the work was large and will be useful in the future but we 
> are not ready to have the system installed like this.
> no-one wants to see 750 packages show up when you do an enquiry on a 
> newly installed system.
> I could live with:
> 
> base-utils11.1
>   - ktrace  uninstalled
>   - tcpdump uninstalled
>   + dd  11.1.1   (CVE-123412 fix)
> 
> 
> 
> but not
> {700 packages )
> dd  11.1.1 dd with CVE fix
> {29 more packages}
> [tcpdump line is not present but you don't notice that]
> {10 more packages}
> [ktrace line would be here but you don't notice that either]
> {15 more packages}
> 
> 
> In other words, I have no objection to all the utilities coming in the
> form of little packages.
> but I have a major objection if that fact is at all obvious to the end
> user,
> and certainly if we need to wade through 750 packages to see what's
going
> on.
> 
>>
>> thanks.
>> -Alfred
>>
>> On 4/18/16 1:07 PM, Lev Serebryakov wrote:
>>> On 18.04.2016 22:40, Glen Barber wrote:
>>>
 This granularity allows easy removal of things that may not be wanted
 (such as *-debug*, *-profile*, etc.) on systems with little 
 storage.  On
 one of my testing systems, I removed the tests packages and all debug
 and profiling, and the number of base system packages is 383.
>>>   IMHO, granularity like "all base debug", "all base profile" is 
>>> enough
>>> for this. Really, I hardly could imagine why I will need only 1 
>>> debug or
>>> profile package, say, for csh. On resource-constrained systems NanoBSD
>>> is much better anyway (for example, my typical NanoBSD installation is
>>> 37MB base system, 12MB /boot and 10 packages), and on developer system
>>> where you need profiled libraries it is Ok to install all of them and
>>> don't think about 100 packages for them.
>>>
>>>   Idea of "Roles" from old FreeBSD installers looks much better. 
>>> Again,
>>> here are some "contrib" software which have one-to-one replacements in
>>> ports, like sendmail, ssh/sshd, ntpd, but split all other
>>> FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static 
>>> libraries.
>>> Yes, lib32 on 64 bit system.
>>>
>>>It seems that it is ideological ("holy war") discussion more than
>>> technical one...
>>>
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, 

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> 
> And nowhere did it say "buildworld/buildkernel would no longer work."
> 
> Glen


It may very well work, but you consider a listing of hundred of packages
on  a 
fresh system a sane default ? 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

libxofication of FreeBSD kernel ? 201506DevSummit

[dan_partelly]

Hi all,


At the following URL:

https://wiki.freebsd.org/201506DevSummit/libxo

the listed agenda of libxo working group include the following topic of
discussion:

 Discussion: libxo in the kernel.  -

Can someone please explain exactly what happens here ? Who pushed this
agenda , 
regarding libxo in kernel,  and what was discussed ? 


For me it is worrisome that such a topic of discussion even exists. It is
my opinion 
that engineers should strive to simplify a kernel, even reduce their size
in  
LOC where possible, not adding complexity, especially totally unjustified
complexity. 


But I would like to hear the whole story before passing judgment on the
issue. 


Dan

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

Re: DDB patches

[dan_partelly]

Hi Pedro,


Sure, no worries , I am grateful for all you did, couldn't ask for more.

I have yet no idea how the projects works, but in the thread in which I
questioned the wisdom of having 
utilities in base spitting out JSON -- instead of properly libyifing some
utilities -- Adrian has
stated something which I perceived to be on the line "everybody talks,
noone codes". So I expressed
my willingness to participate to libifing some utilities from base, but ,
understandingly I  hope,
I want to see how this process goes with code which already existed , 
before investing  time in created new code

So once again, I thank you !




On Thu, 19 Nov 2015 10:08:57 -0500, Pedro Giffuni  wrote:
>> Il giorno 19/nov/2015, alle ore 04:57, Dan Partelly
>>  ha scritto:
>> 
>> Hey Pedro,
>> 
>> Thanks a lot , mate. 
>> 
>> I’m reluctant to put it up as a PR, since some PR are outstanding for
>> years.
>> 
> 
> Well, that’s the way the project works: you cannot really depend on me,
or
> anyone else keeping old patches around. If you want a record of your
> submission bugzilla is the place to keep it. And of course there is no
> guarantee
> anyone will look at it but your chances are much better in bugzilla than
> in a mailinglist.
> 
> 
> 
>> Adrian,
>> 
>> since Pedro has issue with hardware, could you try the patch and give a
>> resolution on it ? I reviewed it mentally (no FreeBSD atm machine on
>> which I could actually  patch the kernel)  and apart style changes it
>> looks OK . Physically i can test it again fro a couple of days.
> 
> Mental reviews don’t count much: if you are not running FreeBSD and
> standing
> behind your patch the chances of being taking seriously are slim.
> 
> 
>>  Getting this reviewed & tested / committed or rejected would give me
an
>>  idea on how things actually work around here. This is actual code
which
>>  you can commit or reject not commentaries only like in the thread
>>  regarding the binary code reuse.
>> 
>> 
> 
> I recall you stated the patch was “not ready” when you posted it. I
> haven’t really
> done anything to say it is ready. Unless someone else finds time to do
real
> testing it won’t happen.
> 
> Adrian tends to do some particularly valuable contributions to the
> project. I
> would prefer if he spends his time on more important tasks.
> 
>> [qute from libxo thread ]
 It's all fine and good making technical decisions based on drawings
 and handwaving and philosophizing, but at some point someone has to
do
 the code.
 The reason is simple - someone offered to do the work and push it
 through. This isn't a commercial thing where we get to make project
 >>decisions and allocate resources - the juniper folk came up with a
 solution that
>> 
>> Once I see how things work around here once someone wrote  the code, 
>> and get this done one way or another , we could proceed to the
>> libification of ifconfig, should you so desire, and you believe we can
>> all benefit from it.
>> 
> 
> Wrong approach. You can’t really blackmail someone into taking your
> changes.
> 
> Things work like this:
> 
> - You discuss your idea and try to get some consensus in the
> lists/IRC/conferences.
> - You *write* a specific proof of concept and get it discussed.
> - You finish your prototype.
> - Your work gets rejected until you get something some committer is
> willing to support.
> - When there are no objections and a committer feels like it, your work
> gets committed,
>  which doesn’t necessarily mean it will stay.
> - You are expected to maintain it.
> 
> Libxo already went through this process.
> 
> We are particularly NOT interested in code where the original
contributor
> will walk
> away as soon as he/she receives criticism or has plans that do not match
> ours.
> If this is not your ideal workflow … fork your own BSD, a lot of
> intelligent
> people do just that.
> 
> Pedro.
> 
>> 
>> Dan
>> 
>> 
>> 
>>> On 19 Nov 2015, at 11:17, Pedro Giffuni  wrote:
>> 
>>> 
>>> Hello;
>>> 
 Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly
  ha scritto:
 
 Hey Pedro,
 
 some times ago you got some DDB patches from me in which I added
 relational ops support from it. The patch was a bit clobbered,
 but last I know you cleaned it up and put it somewhere on freebsd.org
 (prolly your page) up for review.
 
>>> 
>>> It’s here:
>>> https://people.freebsd.org/~pfg/patches/ddb.patch
>>> 
>>> I haven’t tested it though.
>>> 
 Could you or Adrian review the patch set , and if it is OK
potentially
 proceed with a commit ? Or if it is not ok for a commit , please
advice
 on a follow up.
 
>>> 
>>> I am having hardware issues so I won’t be able to do much in a while.
>>> Perhaps you should review it and submit it as a PR.
>>> 
>>> Pedro.
>>> 
>> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> 

Re: libXO-ification - Why - and is it a symptom of deeper issues?

[dan_partelly]

Software wise, your biggest competitive advantage is using a re-branded
BSD operating system.  

On a more serious note, surely I understand and support this position. The
BSD license stays 
for true freedom, unlike the GNU beer . 

But we would never be sure that your company would say no, unless someone
asks. SO I asked here
on this list.What do you say Simon, would you please relay to Juniper
decision factors 
my plea to open source your rights management system back in the BSD
source code pool? 

Then we would know for sure if the answer is yes of no. Answer which of 
course will be respected of the BSD community.


On Tue, 17 Nov 2015 10:00:30 -0800, "Simon J. Gerraty" 
wrote:
> Dan Partelly  wrote:
>> Management daemon with fine grained permission, extremely
>> useful. Would Juniper consider donating to FreeBSD under a BSD license
>> portions of this code, the MGD, which could be reused in FreeBSD ? A
> 
> Right now I suspect the answer to that might be "no".
> We know we have competitors who would dearly like that ;-)
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RFC - DDB relops,logical ops,bitwise ops

[dan_partelly]

Hi all,

I attach a patch for comments (the patch is not final is intended for
comments only, format for one thing is messed ) 
regarding support for !=, ==, , , =, = , ! , ~,  , | ,  , ||
operators in DDB expressions.

The code was mainly pulled from Mach 3.0 kernel with a couple of bug-fixes
 I added them in my copy mainly
because I am interested in crafting conditional breakpoints later. (and
some other DDB usability enhancements).
Please share your opinions. 

Regards!diff --git ddb/db_expr.c ddb/db_expr.c
index b9aebce..9f69f84 100644
--- ddb/db_expr.c
+++ ddb/db_expr.c
@@ -43,6 +43,9 @@ static boolean_t	db_mult_expr(db_expr_t *valuep);
 static boolean_t	db_shift_expr(db_expr_t *valuep);
 static boolean_t	db_term(db_expr_t *valuep);
 static boolean_t	db_unary(db_expr_t *valuep);
+static boolean_t db_logical_or_expr(db_expr_t *valuep);  
+static boolean_t db_logical_and_expr(db_expr_t *valuep);
+static boolean_t db_logical_relation_expr(db_expr_t *valuep);
 
 static boolean_t
 db_term(db_expr_t *valuep)
@@ -54,8 +57,8 @@ db_term(db_expr_t *valuep)
 	if (!db_value_of_name(db_tok_string, valuep) 
 		!db_value_of_name_pcpu(db_tok_string, valuep) 
 		!db_value_of_name_vnet(db_tok_string, valuep)) {
-		db_error(Symbol not found\n);
-		/*NOTREACHED*/
+db_error(Symbol not found\n);
+/*NOTREACHED*/
 	}
 	return (TRUE);
 	}
@@ -81,18 +84,18 @@ db_term(db_expr_t *valuep)
 	}
 	if (t == tDOLLAR) {
 	if (!db_get_variable(valuep))
-		return (FALSE);
+return (FALSE);
 	return (TRUE);
 	}
 	if (t == tLPAREN) {
 	if (!db_expression(valuep)) {
-		db_error(Syntax error\n);
-		/*NOTREACHED*/
+db_error(Unmatched ()s\n);
+/*NOTREACHED*/
 	}
 	t = db_read_token();
 	if (t != tRPAREN) {
-		db_error(Syntax error\n);
-		/*NOTREACHED*/
+db_error(Syntax error\n);
+/*NOTREACHED*/
 	}
 	return (TRUE);
 	}
@@ -108,19 +111,35 @@ db_unary(db_expr_t *valuep)
 	t = db_read_token();
 	if (t == tMINUS) {
 	if (!db_unary(valuep)) {
-		db_error(Syntax error\n);
-		/*NOTREACHED*/
+db_error(Expression syntax error after '-'\n);
+/*NOTREACHED*/
 	}
 	*valuep = -*valuep;
 	return (TRUE);
 	}
+	if ( t == tEXCL) {
+	if(!db_unary(valuep)) {
+	db_error(Expression syntax error after '!'\n);
+	/* NOTREACHED  */
+}
+*valuep = (!(*valuep));
+return (TRUE);
+}
+if (t == tBIT_NOT) {
+if(!db_unary(valuep)) {
+db_error(Expression syntax error after '~'\n);
+/* NOTREACHED */
+}
+*valuep = (~(*valuep));
+return (TRUE);
+}
 	if (t == tSTAR) {
 	/* indirection */
 	if (!db_unary(valuep)) {
-		db_error(Syntax error\n);
+db_error(Expression syntax error after '*'\n);
 		/*NOTREACHED*/
 	}
-	*valuep = db_get_value((db_addr_t)*valuep, sizeof(void *), FALSE);
+*valuep = db_get_value((db_addr_t)*valuep, sizeof(void *), FALSE);
 	return (TRUE);
 	}
 	db_unread_token(t);
@@ -137,14 +156,20 @@ db_mult_expr(db_expr_t *valuep)
 	return (FALSE);
 
 	t = db_read_token();
-	while (t == tSTAR || t == tSLASH || t == tPCT || t == tHASH) {
+	while (t == tSTAR || t == tSLASH || t == tPCT || t == tHASH
+	|| t == tBIT_AND ) {
 	if (!db_term(rhs)) {
-		db_error(Syntax error\n);
-		/*NOTREACHED*/
+db_error(Syntax error\n);
+/*NOTREACHED*/
 	}
-	if (t == tSTAR)
-		lhs *= rhs;
-	else {
+	switch(t)  {
+case tSTAR:
+lhs *= rhs;
+break;
+case tBIT_AND:
+lhs = rhs;
+break;
+default:
 		if (rhs == 0) {
 		db_error(Divide by 0\n);
 		/*NOTREACHED*/
@@ -168,20 +193,25 @@ db_add_expr(db_expr_t *valuep)
 {
 	db_expr_t	lhs, rhs;
 	int		t;
+	char c;
 
 	if (!db_mult_expr(lhs))
 	return (FALSE);
 
 	t = db_read_token();
-	while (t == tPLUS || t == tMINUS) {
+	while (t == tPLUS || t == tMINUS || t == tBIT_OR) {
 	if (!db_mult_expr(rhs)) {
-		db_error(Syntax error\n);
-		/*NOTREACHED*/
+	c = db_tok_string[0];
+db_printf(Expression syntax error after '%c'\n,c);
+db_error(NULL);
+/*NOTREACHED*/
 	}
 	if (t == tPLUS)
-		lhs += rhs;
-	else
-		lhs -= rhs;
+lhs += rhs;
+	else if (t == tMINUS)
+lhs -= rhs;
+else 
+lhs |= rhs;
 	t = db_read_token();
 	}
 	db_unread_token(t);
@@ -201,18 +231,18 @@ db_shift_expr(db_expr_t *valuep)
 	t = db_read_token();
 	while (t == tSHIFT_L || t == tSHIFT_R) {
 	if (!db_add_expr(rhs)) {
-		db_error(Syntax error\n);
-		/*NOTREACHED*/
+db_error(Syntax error\n);
+/*NOTREACHED*/
 	}
 	if (rhs  0) {
-		db_error(Negative shift amount\n);
-		/*NOTREACHED*/
+db_error(Negative shift amount\n);
+/*NOTREACHED*/
 	}
 	if (t == tSHIFT_L)
-		lhs = rhs;

Re: 10-RC2 current wireless link aggregation not working correctly

[dan_partelly]

Guys,


Id like to work a bit on this issue in my free time, I have 2 weeks
holiday
after Xmass. 

First an update on lagg for the case you boot with wired coupled:

1. I previously said lagg0 switches correctly when I unplug the wired 
interface, but it is not so. It appeared so because I used ifconfig
and listed all interfaces. If I do a ifconfig lagg0 specifically
the network activity DOES NOT resume, and  the output shows that the 
interface was not switched.
2. network activity resumes when you specifically do ifconfig bge0 (
master wired). 


Second:

1. Please tell me if one of the developers made on their personal pages
a intro how to set up a solid kernel development intro. It would save me 
a lot  of time considering I never set up such an environment for 
any Unix like OS. I only worked in kernel development for NT and later 
derived kernels. I can allocate two core 2 machines for this task , with 
fire-wire, USN and Ethernet connectivity

2. Any other resources which you can come up from your head which I can
print and read are also appreciated. 

Dan


On Tue, 17 Dec 2013 12:11:49 -0800, Adrian Chadd adrian.ch...@gmail.com
wrote:
 Ive no idea sorry. Its likely an ifnet change and not anything WiFi
 specific. :( On Dec 17, 2013 12:04 PM, dan_partelly  wrote:
 
  Yes, this is correct. A simple list of the interfaces with ifconfig
  makes the system recover and restart activity on the secondary port.
  Its a good starting point to hunt down the problem. One of the ioctls
 sent
  has this side effect.
 
  Dan
 
   If I am am understanding correctly, Dan and Nikolai say that just
   running ifconfig brings the lagg back to life. Why would that make a
   difference at all? Running ifconfig with no parameters shouldnt be
   changing anything.
  ___
  freebsd-current@freebsd.org [2] mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current [3]
  To unsubscribe, send any mail to
 freebsd-current-unsubscr...@freebsd.org [4]
  
 
 Links:
 --
 [1] mailto:dan_parte...@rdsor.ro
 [2] mailto:freebsd-current@freebsd.org
 [3] http://lists.freebsd.org/mailman/listinfo/freebsd-current
 [4] mailto:freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

10-RC2 current wireless link aggregation not working correctly

[dan_partelly]

Hi all,

I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as
described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. 

What happens is:

If I boot the system with the Ethernet cable attached, I correctly get
lagg0 active port on master- bg0- and the network is working correctly.
(I mainly test pinging my gateway). When I pull the cable out, lagg0
device correctly switches to wlan0 as shown by ifconfig (wlan0 is created
from wpi0), but at the same time I get no more ping replies from my
gateway. I can leave the system in this state for several minutes as an
example
and no replies are coming through. A simple list of interfaces with
ifconfig with no parameters brigs the network back to life, and I start to
get back the due ping replyes, this time thrugh wireless link. 


Please, if possible en-light me on tis problem. I sat at your disposition
with any info you may deem necessary to get this fixed (if it needs a fix).


Dan

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

Re: 10-RC2 current wireless link aggregation not working correctly

[dan_partelly]

On Tue, 17 Dec 2013 07:54:52 -0800, Adrian Chadd adr...@freebsd.org
wrote:
 Hi,

All 3 MACs are the same. wpi0 is set to the MAC of bg0. Wlan0 inherits the
MAC of 
wpi0. Lagg0 is set up to the MAC of master. So everything checks out. All 
are the same.

I have to check if the systems sends packets to the gateway after the
switch on wlan0, 
but fails to get any packets back. I didnt had time yet for this. 

 If someone wants to make it supported then they need to claim it. :)

Who from the FreeBSD team supports it ?

Dan



 
 The MAC of the lagg needs to be the same as the wireless interface.
 
 I'm going to just state right now that using lagg as the failover
 method for doing wireless/wired integration isn't supported by me. If
 someone wants to make it supported then they need to claim it. :)
 
 
 -a
 
 
 On 17 December 2013 05:06, dan_partelly dan_parte...@rdsor.ro wrote:

 Hi all,

 I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as
 described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop.

 What happens is:

 If I boot the system with the Ethernet cable attached, I correctly get
 lagg0 active port on master- bg0- and the network is working correctly.
 (I mainly test pinging my gateway). When I pull the cable out, lagg0
 device correctly switches to wlan0 as shown by ifconfig (wlan0 is
created
 from wpi0), but at the same time I get no more ping replies from my
 gateway. I can leave the system in this state for several minutes as an
 example
 and no replies are coming through. A simple list of interfaces with
 ifconfig with no parameters brigs the network back to life, and I start
 to
 get back the due ping replyes, this time thrugh wireless link.


 Please, if possible en-light me on tis problem. I sat at your
disposition
 with any info you may deem necessary to get this fixed (if it needs a
 fix).


 Dan

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

Re: 10-RC2 current wireless link aggregation not working correctly

[dan_partelly]

No problem. Can you point me to the relevant source files in the 
kernel tree, please ?

Dan


On Tue, 17 Dec 2013 08:43:09 -0800, Adrian Chadd adr...@freebsd.org
wrote:
 I'm the wireless stack maintainer and I currently don't support that.
 
 Sorry.
 
 
 
 -a
 
 On 17 December 2013 08:10, dan_partelly dan_parte...@rdsor.ro wrote:
 On Tue, 17 Dec 2013 07:54:52 -0800, Adrian Chadd adr...@freebsd.org
 wrote:
 Hi,

 All 3 MACs are the same. wpi0 is set to the MAC of bg0. Wlan0 inherits
 the
 MAC of
 wpi0. Lagg0 is set up to the MAC of master. So everything checks out.
All
 are the same.

 I have to check if the systems sends packets to the gateway after the
 switch on wlan0,
 but fails to get any packets back. I didnt had time yet for this.

 If someone wants to make it supported then they need to claim it. :)

 Who from the FreeBSD team supports it ?

 Dan




 The MAC of the lagg needs to be the same as the wireless interface.

 I'm going to just state right now that using lagg as the failover
 method for doing wireless/wired integration isn't supported by me. If
 someone wants to make it supported then they need to claim it. :)


 -a


 On 17 December 2013 05:06, dan_partelly dan_parte...@rdsor.ro wrote:

 Hi all,

 I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as
 described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop.

 What happens is:

 If I boot the system with the Ethernet cable attached, I correctly
get
 lagg0 active port on master- bg0- and the network is working
correctly.
 (I mainly test pinging my gateway). When I pull the cable out, lagg0
 device correctly switches to wlan0 as shown by ifconfig (wlan0 is
 created
 from wpi0), but at the same time I get no more ping replies from my
 gateway. I can leave the system in this state for several minutes as
an
 example
 and no replies are coming through. A simple list of interfaces with
 ifconfig with no parameters brigs the network back to life, and I
start
 to
 get back the due ping replyes, this time thrugh wireless link.


 Please, if possible en-light me on tis problem. I sat at your
 disposition
 with any info you may deem necessary to get this fixed (if it needs a
 fix).


 Dan

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

Re: 10-RC2 current wireless link aggregation not working correctly

[dan_partelly]

Yes, this is correct. A simple list of the interfaces with ifconfig
makes the system recover and restart activity on the secondary port.
Its a good starting point to hunt down the problem. One of the ioctls sent
has this side effect.

Dan




 If I am am understanding correctly, Dan and Nikolai say that just
 running 'ifconfig' brings the lagg back to life. Why would that make a
 difference at all? Running ifconfig with no parameters shouldn't be
 changing anything.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 10-RC2 current wireless link aggregation not working correctly

[dan_partelly]

What claims you do not believe ? Not important anyway. This is 
engineering, so you need not believe, you need to know. Go and replicate 
the bug. You will know then.


 
 I don't really believe these claim.
 
 I had similar issue in the past and found an 'arp -a -d' would fix
 it so I didn't pursued further but I think this would be an
 interesting problem to get addressed.
 
 If I would take an guess, I would start from making lagg(4) interface
 to initiate one or a few gratuitous ARP broadcast when the active port
 changes.  Some switches could use this to kick out their (outdated)
 memory of where the port is.
 
 Cheers,
 - -- 
 Xin LI delp...@delphij.nethttps://www.delphij.net/
 FreeBSD - The Power to Serve!   Live free or die
 -BEGIN PGP SIGNATURE-
 
 iQIcBAEBCgAGBQJSsPQLAAoJEJW2GBstM+nsyXoP/RCeHdu1PVCooIUxzjhqWMJG
 3RyN9i85O1WYpgZwHCSC9mkFKM6GjEIiyaNKCvdYzN/k+d9aCQSXIShgIGutM6ie
 hFD4GCGrevjquHCddpULlUE+iwj0qIJWSyRMusUgo+ya+Bc/4H+szoxTndXaaamz
 CPkZMuzga8kEApXgMvImGfsqB8FqqFNtEELlRmISEHb04iAGqUv6HwoL1DhqEZ3I
 tQQi73JvuCU3Lfbp4CDI0IeTzlAoARBX/mWFjlDm7CA8clu4PzIVhdsRxRUhXIId
 ijI8432al9XXt0m4+4LIKmJa6DlyvQ3pIZDFodryQ1za3PAaF7IheILFKPi9BAwi
 Tn47X2+2XYXx7ZS2S22R7KRgeORZqj2uYZifs/xsNwkBCsyntYZgH+c5qYU7TWb/
 tWRi9c5uVFskoPx4JL4W3ctgPvN7TpvKeCBLZTBdLQjy9WT6sqhxChxS57SFT5AH
 kTOWNEA0PqWjrrqRlNO47TL/aTg3Js9S4KxIZ2+hHSkDAlMxGi9rHzyHYPQKxJ1V
 lLmLGN0ZRYGGKa4Yn2OBAy16q/I2jkLE0Nkb0u1V3EEMkKQWp6pcro/Kb9Hrirfe
 n6zrFVyzLTIgNpr9C1+By1CxAmJfg73cIoobJSjNDZ2+EpY+FRDdhKYip3xtpNfA
 QFmabonocmaEohNcC8me
 =mSYS
 -END PGP SIGNATURE-
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 10-RC2 current wireless link aggregation not working correctly

[dan_partelly]

I guarantee you that a simple interface list with ifconfig un-stucks the 
net on my setup, at lest in the case (master is wired, unplug ethernet, 
fail to wireless) I agree that it doesn't makes much sense, but no matter
 how unlikely it seems, it is a **fact**.




 
 I don't believe in merely doing 'ifconfig' would workaround the issue,
 it does not make sense, plus I have tested and it didn't work for my
 case (iwn+em on my laptop).
 
 I'm aware of the issue but thought it was compatibility issue with my
 own weirdly setup wireless AP at the time, and looks like it's not
 just me, but I'm not interested nor have time to fix the problem so I
 replied the thread and offered what I have tested as a workaround in
 the hope that it's useful for someone who is interested and have the
 ability to fix the problem.
 
 Cheers,
 -BEGIN PGP SIGNATURE-
 
 iQIcBAEBCgAGBQJSsVEkAAoJEJW2GBstM+nswTsP/Rs0hdyXNejf2Z98GbSGns0n
 lsI+UmjwWUSg0h+8QzCce7/80mwEw0tZH1btoRr6I0tPKXwdUYDO2C3LPM2a/jSV
 hvN6aay0ppnldtsqMZcuDv1OznSGfEIt0A04/m/RUTDBYaPKY+F1iqZYNE960zes
 u6mbR2elpAUCHjpV3lEchnP5V1v/yLpVziGYabR4WLwohtlOMGVbL92ejLAeKVnr
 Ar7SiWA7GVar6lSGBWyyGwoErveb8TaZxRiSKgjHuvciMLgy+KrlyxqZq6gNd7nP
 isBDMEe2NsnUawR/gfcxvvzpyHTPYPtSlEJjejdbnGlP4YGy5BT2vm3HqyAgK/iX
 N1iRBhx8zuH9UDNN8XiSuvuYuxAw9OfeBoh/2aGifj5dcrEP+IeyYUoAWBoXgny+
 IcoitmUwYE4xLduLnIpf2b5KG8Yw1r2bKoZJVOw8+ixJAqCWR0xXONcywB56MXoE
 8r9A11D6ASdRmozKjcEQH9+j6/4VuVeydCBfXQSZHIlVL3pTFZAlH0Q0JSZq4NXA
 Pb5YGcdYDONi3gPxNIvUn1WeqTfpgJhGveKV5PhI3NY2d+GEB3fBBuBhvlAlrwxg
 CPCqH4YC0sntvqMqcOooz44OfiLpB1ARGGTwtKATLNIzpS/iMsS1swW1NZEeaN19
 uFZw/dY3w5uhDQ7u2Buc
 =4ByJ
 -END PGP SIGNATURE-
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org