Re: Core: Yes please, Code of Conduct committee: No Thanks.
> http://phk.freebsd.dk/sagas/israel/ Usual anti-semitic rant, nothing special. Arrogant, ignorant, hateful, bad grammar. I've seen too much of this stuff in the UK lately. The only thing missing is "some of my best friends are jews". In some EU countries anti-semitic speech is a crime, e.g. UK or Germany. Perhaps not in the country where the author resides. Still he might want to check the international definition of anti-semitism: https://antisemitism.uk/definition/ to see examples very similar to what he has written. As far as the project is concerned - unless there is "official" endorsement of the author's views (whatever that means for a open source project), I guess it's just another individual with his anti-semitic views. Anton Shterenlikht ___ 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: Core: Yes please, Code of Conduct committee: No Thanks.
On Tue, May 21, 2019 at 2:28 PM Dima Pasechnik
wrote:
> On Sat, May 11, 2019 at 3:25 PM Julian H. Stacey wrote:
> >
> > FreeBSD Core Team Secretary wrote:
> > > The FreeBSD Core Team is aware of recent controversial statements made
> > > on social media by a FreeBSD developer. We, along with the Code of
> > > Conduct review committee, are investigating the matter and will decide
> > > what action to take. Both the Core Team and the FreeBSD Foundation
> > > would like to make it clear that views shared by individuals represent
> > > neither the Project nor the Foundation.
> >
> > Core@ statements always welcome.
> >
> > But Code of Conduct committee merit no automatic credence since:
> >
> > Code of Conduct aims were cloned from an ultra feminist group of
> > non FreeBSD members, part paid by foundation, then shoved on
> > FreeBSD before discussion, by a voluble few in FreeBSD
>
> The present matter has nothing to do with feminism.
I don't see who states that.
Anyway, as someone
> who has been chased upon by a gang of youths screaming "zhidovskaya
> morda" ("Jewish snout") (Moscow, USSR, circa 1975, tough
> neighbourhood, and well, I have a Jewish grandmother) I absolutely do
> not appreciate the sort of thoughtless "freedom of speech" blah blah,
> as far as expressions of hate towards particular ethnic groups are .
>
Just wondering how old were you and "haters" were. In my childhood I was
laughed on because having too big ears, another girl - because she was fat,
and another guy - because his dad was an alcoholic. I'd argue that being
bulled by "jewish snout" words instead of "fatty" puts you in some special
position amongst these people and me.
Yes, the phenomenom is bad in its nature, but it is also so common and
insignificant, that IMO it doesn't serve all that fuss.
Because they always incite violence.
> And yes, in USSR persons with ethnically Jewish parents had "Jew"
> written in their internal IDs (just like in Nazi Germany). Under this
> commonly accepted definition, saying "I hate Jews", as Mr. Kamp did on
> twitter, is full-blown racism,
I'd like to hear how it is "commonly accepted". I don't remember accepting
anything related.
and Mr. Kamp ought to offer an apology
> for this - while he does not do it in
> http://phk.freebsd.dk/sagas/israel/
>
> While in some jurisdictions hate speech is legally protected, it does
> not take away the hate in hate speech, and people generally don't like
> being hated. Hate originating from a freebsd.* domain is not good for
> the project.
>
freebsd.* domain can be registered by any individual, so hate originating
from such domains can't (well, shouldn't) affect the project in any way.
On the contrary, hate originating from *.freebsd.org, it does affect the
project. Luckily, this is not the case.
> Let me point few things in the latter:
>
> * there is nothing like "the jewish religion" - there is a religion
> called Judaism, as Mr. Kamp ought to understand before
> making statements on these. Everyone can convert to Judaism, by the way.
>
Thanks for valuable information. It is completely off-topic and I doubt
anyone here have any interest in this.
> * Jews who are not Israeli citizens are about as responsible for
> policies of Israel as descendants of Vikings areresponsible for
> policies of Scandinavian states of today.
>
> * I don't know anything about the legal status of the domain
> "freebsd.dk" --- nevertheless I don't think it does do much good to
> the reputation of FreeBSD to have these slightly illiterate writings
> there (although it might be bringing Mr.Kamp lucrative contracts from
> such pillars of democracy and free thought and speech as Saudi Arabia,
> Syria, and Iran :-))
>
> Best,
> Dima
> http://users.ox.ac.uk/~coml0531/
>
>
>
>
> >
> > The new CoC terms were hotly disputed. core@ failed to remove it
> > before many tuned out, despairing of the politics [& lack of core@
> > backbone, probably themselves scared of being labeled anti-whatever],
> >
> > New CoC putch-ists took seats on CoC
> >
> > FreeBSD had a CoC before the putch with the new feminist etc CoC.
> > https://www.freebsd.org/internal/code-of-conduct.html
> > CoC could be replaced with the old one from SVN, or from
> >
> https://web.archive.org/web/*/https://www.freebsd.org/internal/code-of-conduct.html
> >
> > Cheers,
> > Julian
> > --
> > Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich
> Aachen Kent
> >
Re: Core: Yes please, Code of Conduct committee: No Thanks.
On Tue, 21 May 2019 at 11:30, Dima Pasechnik wrote:
> Anyway, as someone
> who has been chased upon by a gang of youths screaming "zhidovskaya
> morda" ("Jewish snout") (Moscow, USSR, circa 1975, tough
> neighbourhood, and well, I have a Jewish grandmother)
You're conflating freedom of expression with wanton action of agression
> I absolutely do
> not appreciate the sort of thoughtless "freedom of speech" blah blah,
> as far as expressions of hate towards particular ethnic groups are .
Luckily most societies have more wisdom than you and elect to have
free and open discussion and chose to not oppress.
> Because they always incite violence.
That is a gross overgeneralisation with absolutely zero foundation. If
you say that PHK's expression was hate towards one specific group, and
you assert that that "always" incites violence, what violence followed
PHK's expression? Either show demonstrable violence or your statement
falls flat on its face.
> And yes, in USSR persons with ethnically Jewish parents had "Jew"
> written in their internal IDs (just like in Nazi Germany).
I lived in the USSR, my parents lived in the USSR, my grandparents
lived in the USSR and I don't recall anything of the sort, nor do I
recall a huge jewish population of Odessa, for example, even bringing
this up as an issue during Perestroyka or post break up. Or do you
mean that the USSR passports identified *ethnicity* of the bearer,
like Pole, Ukrainian, Uzbek, Moldav, Jew?.. I think you're taking
things hugely out of context and trying to make something out of
nothing, because if inserting one's ethnicity into a passport or any
state-issued ID is "an act of hate" as you seem to assert, then my UK
driving licence, and by implication the UK Government, is full of
"hate speech"!
> Under this
> commonly accepted definition, saying "I hate Jews", as Mr. Kamp did on
> twitter, is full-blown racism, and Mr. Kamp ought to offer an apology
> for this - while he does not do it in
> http://phk.freebsd.dk/sagas/israel/
I love when people find a text, then select words from it choosing to
omit the rest! Here's how freedom of expression works: A makes a
reasoned expression of opinion/view. B might not like the conclusion
or premise. Any person of reasonably intelligence can (a) ignore A
altogether; (b) engage in a discussion with A (quite frankly PKH's
expression is fully argued, as in he gives his reasons) to change his
mind by counter-arguments; a person without any argument usually
claims some nonsense to get some liberal snowflakes on their side and
try to silence the different view using "megaphone diplomacy."
For what it's worth, I actually read all the statements made by PHK
and there is no incitement of violence or anything of the sort, all he
said was X because of Y. I think his reasoning is a bit stretched and
if one were really interested in what he was saying instead of
obsessively crucifying him, one could change his mind. Hint: that's
the whole premise of "freedom of expression"---someone says something
unpalatable, you engage, you could change their mind, they could
change your mind, or you could agree to disagree... Yet we seem to be
going the way of Romans at best, and some already lining up for a
tameshigiri.
> While in some jurisdictions hate speech is legally protected, it does
> not take away the hate in hate speech, and people generally don't like
> being hated. Hate originating from a freebsd.* domain is not good for
> the project.
Perhaps you could show concrete examples of such "hate" from that
specific domain, I seem to struggle to find any.
> Let me point few things in the latter:
>
> * there is nothing like "the jewish religion" - there is a religion
> called Judaism, as Mr. Kamp ought to understand before
> making statements on these. Everyone can convert to Judaism, by the way.
>
> * Jews who are not Israeli citizens are about as responsible for
> policies of Israel as descendants of Vikings areresponsible for
> policies of Scandinavian states of today.
Oh look, you're perfectly capable of engaging in a reasoned argument
(and these two are a number of reasons why I though his reasoning was
"a bit stretched")! You make good and valid points, so engage, and
change his mind!
--
Igor M.
___
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: Core: Yes please, Code of Conduct committee: No Thanks.
On Tue, May 21, 2019 at 11:47 AM Gleb Popov wrote:
>
>
>
> On Tue, May 21, 2019 at 2:28 PM Dima Pasechnik
> wrote:
>>
>> On Sat, May 11, 2019 at 3:25 PM Julian H. Stacey wrote:
>> >
>> > FreeBSD Core Team Secretary wrote:
>> > > The FreeBSD Core Team is aware of recent controversial statements made
>> > > on social media by a FreeBSD developer. We, along with the Code of
>> > > Conduct review committee, are investigating the matter and will decide
>> > > what action to take. Both the Core Team and the FreeBSD Foundation
>> > > would like to make it clear that views shared by individuals represent
>> > > neither the Project nor the Foundation.
>> >
>> > Core@ statements always welcome.
>> >
>> > But Code of Conduct committee merit no automatic credence since:
>> >
>> > Code of Conduct aims were cloned from an ultra feminist group of
>> > non FreeBSD members, part paid by foundation, then shoved on
>> > FreeBSD before discussion, by a voluble few in FreeBSD
>>
>> The present matter has nothing to do with feminism.
>
>
> I don't see who states that.
>
>> Anyway, as someone
>> who has been chased upon by a gang of youths screaming "zhidovskaya
>> morda" ("Jewish snout") (Moscow, USSR, circa 1975, tough
>> neighbourhood, and well, I have a Jewish grandmother) I absolutely do
>> not appreciate the sort of thoughtless "freedom of speech" blah blah,
>> as far as expressions of hate towards particular ethnic groups are .
>
>
> Just wondering how old were you and "haters" were. In my childhood I was
> laughed on because having too big ears, another girl - because she was fat,
> and another guy - because his dad was an alcoholic. I'd argue that being
> bulled by "jewish snout" words instead of "fatty" puts you in some special
> position amongst these people and me.
> Yes, the phenomenom is bad in its nature, but it is also so common and
> insignificant, that IMO it doesn't serve all that fuss.
My CV may be found online at the link after the signature - I am 56
y.o., and I did experience a fair share of state-amplified and
condoned antisemitism back in USSR (apart from this incident). There
was no state-condoned hate of people with big ears or excessive
weight, and this does make quite some difference.
As to "it is also so common" --- this is the 1st time in more than 27
years, since I left Moscow, that this topic interferes with my
work. While it might be "so common" to you, it does not remove the
hate from the hate speech it is.
>
>> Because they always incite violence.
>> And yes, in USSR persons with ethnically Jewish parents had "Jew"
>> written in their internal IDs (just like in Nazi Germany). Under this
>> commonly accepted definition, saying "I hate Jews", as Mr. Kamp did on
>> twitter, is full-blown racism,
>
>
> I'd like to hear how it is "commonly accepted". I don't remember accepting
> anything related.
Are you trying to tell us that "5th paragraph", ethnicity, never was
present in internal USSR passports?
Of course it was, and on the basis of this I dare to say that my
definition was commonly accepted in the USSR.
And in present days Europe "jew" need not refer to a religious affiliation.
(about 40% of Israeli citizens describe themselves as secular, by the way).
>
>> and Mr. Kamp ought to offer an apology
>> for this - while he does not do it in
>> http://phk.freebsd.dk/sagas/israel/
>>
>> While in some jurisdictions hate speech is legally protected, it does
>> not take away the hate in hate speech, and people generally don't like
>> being hated. Hate originating from a freebsd.* domain is not good for
>> the project.
>
>
> freebsd.* domain can be registered by any individual, so hate originating
> from such domains can't (well, shouldn't) affect the project in any way.
> On the contrary, hate originating from *.freebsd.org, it does affect the
> project. Luckily, this is not the case.
>
>>
>> Let me point few things in the latter:
>>
>> * there is nothing like "the jewish religion" - there is a religion
>> called Judaism, as Mr. Kamp ought to understand before
>> making statements on these. Everyone can convert to Judaism, by the way.
>
>
> Thanks for valuable information. It is completely off-topic and I doubt
> anyone here have any interest in this.
As Mr. Kamp's blog post is being discussed here, I felt it might be
appropriate to point out why it was an a
Re: Core: Yes please, Code of Conduct committee: No Thanks.
On Sat, May 11, 2019 at 3:25 PM Julian H. Stacey wrote:
>
> FreeBSD Core Team Secretary wrote:
> > The FreeBSD Core Team is aware of recent controversial statements made
> > on social media by a FreeBSD developer. We, along with the Code of
> > Conduct review committee, are investigating the matter and will decide
> > what action to take. Both the Core Team and the FreeBSD Foundation
> > would like to make it clear that views shared by individuals represent
> > neither the Project nor the Foundation.
>
> Core@ statements always welcome.
>
> But Code of Conduct committee merit no automatic credence since:
>
> Code of Conduct aims were cloned from an ultra feminist group of
> non FreeBSD members, part paid by foundation, then shoved on
> FreeBSD before discussion, by a voluble few in FreeBSD
The present matter has nothing to do with feminism. Anyway, as someone
who has been chased upon by a gang of youths screaming "zhidovskaya
morda" ("Jewish snout") (Moscow, USSR, circa 1975, tough
neighbourhood, and well, I have a Jewish grandmother) I absolutely do
not appreciate the sort of thoughtless "freedom of speech" blah blah,
as far as expressions of hate towards particular ethnic groups are .
Because they always incite violence.
And yes, in USSR persons with ethnically Jewish parents had "Jew"
written in their internal IDs (just like in Nazi Germany). Under this
commonly accepted definition, saying "I hate Jews", as Mr. Kamp did on
twitter, is full-blown racism, and Mr. Kamp ought to offer an apology
for this - while he does not do it in
http://phk.freebsd.dk/sagas/israel/
While in some jurisdictions hate speech is legally protected, it does
not take away the hate in hate speech, and people generally don't like
being hated. Hate originating from a freebsd.* domain is not good for
the project.
Let me point few things in the latter:
* there is nothing like "the jewish religion" - there is a religion
called Judaism, as Mr. Kamp ought to understand before
making statements on these. Everyone can convert to Judaism, by the way.
* Jews who are not Israeli citizens are about as responsible for
policies of Israel as descendants of Vikings areresponsible for
policies of Scandinavian states of today.
* I don't know anything about the legal status of the domain
"freebsd.dk" --- nevertheless I don't think it does do much good to
the reputation of FreeBSD to have these slightly illiterate writings
there (although it might be bringing Mr.Kamp lucrative contracts from
such pillars of democracy and free thought and speech as Saudi Arabia,
Syria, and Iran :-))
Best,
Dima
http://users.ox.ac.uk/~coml0531/
>
> The new CoC terms were hotly disputed. core@ failed to remove it
> before many tuned out, despairing of the politics [& lack of core@
> backbone, probably themselves scared of being labeled anti-whatever],
>
> New CoC putch-ists took seats on CoC
>
> FreeBSD had a CoC before the putch with the new feminist etc CoC.
> https://www.freebsd.org/internal/code-of-conduct.html
> CoC could be replaced with the old one from SVN, or from
>
> https://web.archive.org/web/*/https://www.freebsd.org/internal/code-of-conduct.html
>
> Cheers,
> Julian
> --
> Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent
> http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU.
> Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died.
> ___
> 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"
Core: Yes please, Code of Conduct committee: No Thanks.
FreeBSD Core Team Secretary wrote: > The FreeBSD Core Team is aware of recent controversial statements made > on social media by a FreeBSD developer. We, along with the Code of > Conduct review committee, are investigating the matter and will decide > what action to take. Both the Core Team and the FreeBSD Foundation > would like to make it clear that views shared by individuals represent > neither the Project nor the Foundation. Core@ statements always welcome. But Code of Conduct committee merit no automatic credence since: Code of Conduct aims were cloned from an ultra feminist group of non FreeBSD members, part paid by foundation, then shoved on FreeBSD before discussion, by a voluble few in FreeBSD The new CoC terms were hotly disputed. core@ failed to remove it before many tuned out, despairing of the politics [& lack of core@ backbone, probably themselves scared of being labeled anti-whatever], New CoC putch-ists took seats on CoC FreeBSD had a CoC before the putch with the new feminist etc CoC. https://www.freebsd.org/internal/code-of-conduct.html CoC could be replaced with the old one from SVN, or from https://web.archive.org/web/*/https://www.freebsd.org/internal/code-of-conduct.html Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. ___ 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: cross compiling freebsd-head is sigh, now broken - thanks libllvm
On 19 Mar 2017, at 08:00, Adrian Chadd wrote:
>
> ===> lib/clang (all)
> ===> lib/clang/libllvm (all)
> In file included from
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/math.h:309:0,
> from
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/cmath:305,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/lib/clang/include/llvm/Support/DataTypes.h:34,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/Hashing.h:48,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/ArrayRef.h:13,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMapInfo.h:17,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:17,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/IR/ValueMap.h:29,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Transforms/Utils/ValueMapper.h:18,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/lib/Transforms/Utils/ValueMapper.cpp:15:
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:
> In substitution of 'template static
> std::__1::true_type
> std::__1::__is_constructible_helper::__test_nary(int) [with _Tp =
> {anonymous}::MDNodeMapper::Data; _Args = {};
> = ]':
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:2993:59:
> required from 'struct
> std::__1::__is_default_constructible<{anonymous}::MDNodeMapper::Data,
> false>'
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3015:8:
> required from 'struct
> std::__1::__libcpp_is_constructible<{anonymous}::MDNodeMapper::Data>'
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3043:29:
> required from 'struct
> std::__1::is_constructible<{anonymous}::MDNodeMapper::Data>'
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3229:29:
> required from 'struct
> std::__1::is_default_constructible<{anonymous}::MDNodeMapper::Data>'
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:352:15:
> required from 'static constexpr bool std::__1::pair<_T1,
> _T2>::_CheckArgs::__enable_default() [with _U1 = const
> llvm::Metadata*; _U2 = {anonymous}::MDNodeMapper::Data; _T1 = const
> llvm::Metadata*; _T2 = {anonymous}::MDNodeMapper::Data]'
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:403:71:
> required by substitution of 'template std::__1::enable_if std::__1::pair {anonymous}::MDNodeMapper::Data>::_CheckArgs,
> std::__1::__check_tuple_constructor_fail>::type::
> __enable_default(), bool>::type >
> constexpr std::__1::pair<_T1, _T2>::pair() [with bool _Dummy = true;
> typename std::__1::enable_if std::__1::conditional<_MaybeEnable, std::__1::pair llvm::Metadata*, {anonymous}::MDNodeMapper::Data>::_CheckArgs,
> std::__1::__check_tuple_constructor_fail>::type::
> __enable_default(), bool>::type =
> ]'
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:39:8:
> required from 'struct llvm::detail::DenseMapPair llvm::Metadata*, {anonymous}::MDNodeMapper::Data>'
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Support/AlignOf.h:111:6:
> required from 'class
> llvm::detail::AlignerImpl llvm::Metadata*, {anonymous}::MDNodeMapper::Data> [32],
> llvm::SmallDenseMap {anonymous}::MDNodeMapper::Data, 32u>::LargeRep, char, char, char,
> char, char, char, char, char>'
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Support/AlignOf.h:138:8:
> required from 'struct
> llvm::AlignedCharArrayUnion llvm::Metadata*, {anonymous}::MDNodeMapper::Data> [32],
> llvm::SmallDenseMap {anonymous}::MDNodeMapper::Data, 32u>::LargeRep, char, char, char,
> char, char, char, char, char>'
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:759:59:
> required from 'class llvm::SmallDenseMap {anonymous}::MDNodeMapper::Data, 32u>'
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/lib/Transforms/Utils/ValueMappe
Re: cross compiling freebsd-head is sigh, now broken - thanks libllvm
WITHOUT_CLANG fixed it for me. Thanks. -adrian On 20 March 2017 at 11:23, Ed Maste wrote: > On 19 March 2017 at 03:00, Adrian Chadd wrote: >> gcc version 5.3.0 (FreeBSD Ports Collection for mips) >> >> ... so uhm, why are we building libllvm? > > As of the Clang 4.0.0 import we build Clang by default, on all > architectures other than those unsupported by Clang, if the > cross-compiler supports C++11. > > I'm not sure if the issue you encountered here is in libllvm or GCC. > For now though you can set WITHOUT_CLANG and WITHOUT_CLANG_FULL in > /etc/src.conf. ___ 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: cross compiling freebsd-head is sigh, now broken - thanks libllvm
On 19 March 2017 at 03:00, Adrian Chadd wrote: > gcc version 5.3.0 (FreeBSD Ports Collection for mips) > > ... so uhm, why are we building libllvm? As of the Clang 4.0.0 import we build Clang by default, on all architectures other than those unsupported by Clang, if the cross-compiler supports C++11. I'm not sure if the issue you encountered here is in libllvm or GCC. For now though you can set WITHOUT_CLANG and WITHOUT_CLANG_FULL in /etc/src.conf. ___ 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"
cross compiling freebsd-head is sigh, now broken - thanks libllvm
===> lib/clang (all)
===> lib/clang/libllvm (all)
In file included from
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/math.h:309:0,
from
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/cmath:305,
from
/usr/home/adrian/work/freebsd/head-embedded/src/lib/clang/include/llvm/Support/DataTypes.h:34,
from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/Hashing.h:48,
from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/ArrayRef.h:13,
from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMapInfo.h:17,
from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:17,
from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/IR/ValueMap.h:29,
from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Transforms/Utils/ValueMapper.h:18,
from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/lib/Transforms/Utils/ValueMapper.cpp:15:
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:
In substitution of 'template static
std::__1::true_type
std::__1::__is_constructible_helper::__test_nary(int) [with _Tp =
{anonymous}::MDNodeMapper::Data; _Args = {};
= ]':
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:2993:59:
required from 'struct
std::__1::__is_default_constructible<{anonymous}::MDNodeMapper::Data,
false>'
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3015:8:
required from 'struct
std::__1::__libcpp_is_constructible<{anonymous}::MDNodeMapper::Data>'
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3043:29:
required from 'struct
std::__1::is_constructible<{anonymous}::MDNodeMapper::Data>'
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3229:29:
required from 'struct
std::__1::is_default_constructible<{anonymous}::MDNodeMapper::Data>'
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:352:15:
required from 'static constexpr bool std::__1::pair<_T1,
_T2>::_CheckArgs::__enable_default() [with _U1 = const
llvm::Metadata*; _U2 = {anonymous}::MDNodeMapper::Data; _T1 = const
llvm::Metadata*; _T2 = {anonymous}::MDNodeMapper::Data]'
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:403:71:
required by substitution of 'template::_CheckArgs,
std::__1::__check_tuple_constructor_fail>::type::
__enable_default(), bool>::type >
constexpr std::__1::pair<_T1, _T2>::pair() [with bool _Dummy = true;
typename std::__1::enable_if::_CheckArgs,
std::__1::__check_tuple_constructor_fail>::type::
__enable_default(), bool>::type =
]'
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:39:8:
required from 'struct llvm::detail::DenseMapPair'
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Support/AlignOf.h:111:6:
required from 'class
llvm::detail::AlignerImpl [32],
llvm::SmallDenseMap::LargeRep, char, char, char,
char, char, char, char, char>'
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Support/AlignOf.h:138:8:
required from 'struct
llvm::AlignedCharArrayUnion [32],
llvm::SmallDenseMap::LargeRep, char, char, char,
char, char, char, char, char>'
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:759:59:
required from 'class llvm::SmallDenseMap'
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/lib/Transforms/Utils/ValueMapper.cpp:182:47:
required from here
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:2980:9:
error: constructor required before non-static data member for
'{anonymous}::MDNodeMapper::Data::HasChanged' has been parsed
class = decltype(_Tp(_VSTD::declval<_Args>()...))>
^
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:2980:9:
error: constructor required before non-static data member for
r313487 recovered. Thanks and details.
r313487 feb 9 i386 1200020 ... Without the details for the thank-you, thanks for the recovery assistance. ... I found ABI in /usr/local/etc/pkg.conf which fix the :11 :12 issue at least for now, upgrading 11-CURRENT to 12-CURRENT to fix seamonkey, and 2.46_4 working again maybe until 2.46_5 serious breakage, libevent2 probably relevant. Until then... ... Small concern many tweaks 2004-2016 were reversed to new-install by base.txz which was needed to restore system functionality. I've backup files... nothing out of the ordinary I see though. The main issue now is one, two, OR 14 hour ( or similar ) lockups of Xorg. Repeatable: [ I've yet to savecore when the stuff happens ] >>>>> links -g cannot be clicked upon, xterm can Leaving Xorg, the interface ue0 cannot be bought up [ means no use restarting X without reboot] Reboot fixes it[ Xorg usage] [ ue0 axe0 usage ] One in four times, it is a crash to reboot from Xorg. [ approximate ] at least until the next Xorg update happens by pkg in about three days or less. as it is in ports. The only question unless valid hints at the above, is Xorg crashing ue0 or ue0 crashing Xorg, or some common denominator in CURRENT that affects both like SCHED_ULE or missing compat10x or a delete-old-libs not done recently? Just in case some more expert than I [ who should have maybe stayed on 11-STABLE or even 11-RELEASE so as not to write too many emails tying up persons' time... ] has more clues than I as to the coding behind the .so internals and all. .. Thanks for reading. PS nano yudit lookat gnuls xvt roxterm rsync gcp xclip feh xv gs text2pdf terminator urxvt scrotall useful day-to-day here... ___ 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: Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)
On 8 March 2010, at 12:33, Robert Watson wrote: > > On Mon, 8 Mar 2010, Doug Hardie wrote: > >> I run a number of 4 core systems with em interfaces. These are production >> systems that are unmanned and located a long way from me. Under unusual >> conditions it can take up to 6 hours to get there. I have been waiting to >> switch to 8.0 because of the discussions on the em device and now it sounds >> like I had better just skip 8.x and wait for 9. 7.2 is working just fine. > > Not sure that any information in this survey thread should be relevant to > that decision. This race has existed since before FreeBSD, having appeared > in the original BSD network stack, and is just as present in FreeBSD 7.x as > 8.x or 9.x. When I learned about the race during the early 7.x development > cycle, I added a counter/statistic to measure how much it happened in > practice, but was not able to exercise it in my testing, and so left the > counter in to appear in 7.0 and later so that we could perform this survey as > core counts/etc increase. > > The two likely outcomes were "it is never exercised" and "it is exercised but > only very infrequently", neither really justifying the quite complex change > to correct it given requirements at the time. On-going development work on > the virtual network stack is what justifies correcting the bug at this point, > moving from detecting and handling the race to preventing it from occuring as > an invariant. The motivation here, BTW, is that we'd like to eliminate the > type-stable storage requirement for connection state (which ensures that > memory once used for a connection block is only ever used for connection > blocks in the future), allowing memory to be fully freed when a virtual > network stack is destroyed. Using type-stable storage helped address this > bug, but was primarily present to reduce the overhead of monitoring using > netstat(1). We'll now need to use a slightly more expensive solution (true > reference counts) in that context, although in practice it will almost > certainly be an unmeasurable cost. > > Which is to say that while there might be something in the em/altq/... thread > to reasonably lead you to avoid 8.0, nothing in the TCP timer race thread > should do so, since it affects 7.2 just as much as 8.0. Even if you do see a > non-zero counter, that's not a matter for operational concern, just useful > from the perspective of a network stack developer to understanding timing and > behaviors in the stack. :-) Thanks for the complete explanation. I don't believe the ALTQ issue will affect me. I am not currently using it and do not expect to in the near future. In addition, there was a posting that a fix for at least part of that will be added in a week or so. Given all that it appears its time to start the planning/testing process for 8. ___ 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: Survey results very helpful, thanks!
Doug Hardie wrote: > On 8 March 2010, at 06:53, Robert Watson wrote: > > >> On Sun, 7 Mar 2010, Robert Watson wrote: >> >> >>> If your system shows a non-zero value, please send me a *private e-mail* >>> with the output of that command, plus also the output of "sysctl kern.smp", >>> "uptime", and a brief description of the workload and network interface >>> configuration. For example: it's a busy 8-core web server with roughly X >>> connections/second, and that has three em network interfaces used to load >>> balance from an upstream source. IPSEC is used for management purposes >>> (but not bulk traffic), and there's a local MySQL database. >>> >> I've now received a number of reports that confirm our suspicion that the >> race does occur, albeit very rarely, and particularly on systems with many >> cores or multiple network interfaces. Fixing it is definitely on the TODO >> for 9.0, both to improve our ability to do multiple virtual network stacks, >> but with an appropriately scalable fix in mind given our improved TCP >> scalability for 9.0 as well. >> > > I run a number of 4 core systems with em interfaces. These are production > systems that are unmanned and located a long way from me. Under unusual > conditions it can take up to 6 hours to get there. I have been waiting to > switch to 8.0 because of the discussions on the em device and now it sounds > like I had better just skip 8.x and wait for 9. 7.2 is working just > fine.___ > I don't think its that simple. I run a number of production systems with "em" interfaces, and they get POUNDED. None have had any trouble with 8.x. $ ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:d2:5a:24 inet 67.23.181.70 netmask 0xff00 broadcast 67.23.181.255 media: Ethernet autoselect (100baseTX ) status: active $ uptime 3:27PM up 61 days, 22:34, 1 user, load averages: 5.08, 4.48, 4.28 That's one of the busier ones; it's kinda loafing right now on network I/O (running about 3mbps sustained) but typically operates in the 15-20mbps range to the wild wild net for 6-8 hours in the evening doing what its doing now (handling a very busy forum) plus a few hundred videocast streams The last reboot was to replace a power strip in the colo rack with one that had remote management capability. It hasn't actually crashed since, well, pretty much forever (it was running 7.x before 8.x went to production status) The box is a dual quad-core Xeon running the amd64 codebase. -- Karl ___ 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: Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)
On Mon, 8 Mar 2010, Doug Hardie wrote: I run a number of 4 core systems with em interfaces. These are production systems that are unmanned and located a long way from me. Under unusual conditions it can take up to 6 hours to get there. I have been waiting to switch to 8.0 because of the discussions on the em device and now it sounds like I had better just skip 8.x and wait for 9. 7.2 is working just fine. Not sure that any information in this survey thread should be relevant to that decision. This race has existed since before FreeBSD, having appeared in the original BSD network stack, and is just as present in FreeBSD 7.x as 8.x or 9.x. When I learned about the race during the early 7.x development cycle, I added a counter/statistic to measure how much it happened in practice, but was not able to exercise it in my testing, and so left the counter in to appear in 7.0 and later so that we could perform this survey as core counts/etc increase. The two likely outcomes were "it is never exercised" and "it is exercised but only very infrequently", neither really justifying the quite complex change to correct it given requirements at the time. On-going development work on the virtual network stack is what justifies correcting the bug at this point, moving from detecting and handling the race to preventing it from occuring as an invariant. The motivation here, BTW, is that we'd like to eliminate the type-stable storage requirement for connection state (which ensures that memory once used for a connection block is only ever used for connection blocks in the future), allowing memory to be fully freed when a virtual network stack is destroyed. Using type-stable storage helped address this bug, but was primarily present to reduce the overhead of monitoring using netstat(1). We'll now need to use a slightly more expensive solution (true reference counts) in that context, although in practice it will almost certainly be an unmeasurable cost. Which is to say that while there might be something in the em/altq/... thread to reasonably lead you to avoid 8.0, nothing in the TCP timer race thread should do so, since it affects 7.2 just as much as 8.0. Even if you do see a non-zero counter, that's not a matter for operational concern, just useful from the perspective of a network stack developer to understanding timing and behaviors in the stack. :-) Robert ___ 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: Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)
On 8 March 2010, at 06:53, Robert Watson wrote: > > On Sun, 7 Mar 2010, Robert Watson wrote: > >> If your system shows a non-zero value, please send me a *private e-mail* >> with the output of that command, plus also the output of "sysctl kern.smp", >> "uptime", and a brief description of the workload and network interface >> configuration. For example: it's a busy 8-core web server with roughly X >> connections/second, and that has three em network interfaces used to load >> balance from an upstream source. IPSEC is used for management purposes (but >> not bulk traffic), and there's a local MySQL database. > > I've now received a number of reports that confirm our suspicion that the > race does occur, albeit very rarely, and particularly on systems with many > cores or multiple network interfaces. Fixing it is definitely on the TODO > for 9.0, both to improve our ability to do multiple virtual network stacks, > but with an appropriately scalable fix in mind given our improved TCP > scalability for 9.0 as well. I run a number of 4 core systems with em interfaces. These are production systems that are unmanned and located a long way from me. Under unusual conditions it can take up to 6 hours to get there. I have been waiting to switch to 8.0 because of the discussions on the em device and now it sounds like I had better just skip 8.x and wait for 9. 7.2 is working just fine.___ 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"
Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)
On Sun, 7 Mar 2010, Robert Watson wrote: If your system shows a non-zero value, please send me a *private e-mail* with the output of that command, plus also the output of "sysctl kern.smp", "uptime", and a brief description of the workload and network interface configuration. For example: it's a busy 8-core web server with roughly X connections/second, and that has three em network interfaces used to load balance from an upstream source. IPSEC is used for management purposes (but not bulk traffic), and there's a local MySQL database. I've now received a number of reports that confirm our suspicion that the race does occur, albeit very rarely, and particularly on systems with many cores or multiple network interfaces. Fixing it is definitely on the TODO for 9.0, both to improve our ability to do multiple virtual network stacks, but with an appropriately scalable fix in mind given our improved TCP scalability for 9.0 as well. Thanks for all the responses, Robert N M Watson Computer Laboratory University of Cambridge ___ 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"
Many many many thanks to all that develop FreeBSD.
Hi, When everything is life is just smoothly flowing by, and all is hunky-dory, some things don't get the credits they deserve. So here we go ;) Standing at the coffee machine this morning I realized that FreeBSD has been part of my professional life for already way, way too long. Before 1993 I was tinkering with CPM, SCO, sys3/5, i386, Apollo Domain, Linux <0.98 and sorts. When friends an I decided to start an ISP, then very novel, now really part of our lives. And one of the friends suggested to use FreeBSD instead of Linux. As Linux at that time was still very much in flux and really just a flying target, we were more than up for it. Because if gave us the systems that we were all too familiar with. And it really did work richt out of the box. (well almost, needed to hack on the serial driver for the 16 port card we had) The first commercial server that we deployed was running FreeBSD 1.1. I still fondly keep that CD. One of those friends has been part of the Core team (Guido van Rooij) for a while. And I'm sure that a lot of the code he hacked up to keep the ISP going ended up somewhere in the tree. The release strategy has always been a real nice service to our business. Lots of systems where kept at major_versions, until the hardware became too old. Only then to leapfrog into the most stable version at that moment. And I don't ever recall that we were disappointed in the way FreeBSD developed itself. The ISP was sold in 2000, and I started doing other things. But in 2000 just about everything the ISP was delivering ran on FreeBSD. And I remember boxing being up for over 2 years. (especially those not exposed to the public.:)) Only reason for some windows was, because business wise you can't do without. At home FreeBSD has been my friend from that same moment forward. I trashed my Linux Toys, merged to FreeBSD and never looked back. My home is now running on 2* FreeBSD's and lots of Jave-embeded devices. Again there never disappointed in what FreeBSD delivered. Recently I started a new company again, but much to my disappointment (but understandably so) the chipset supplier (NXP/Philips) delivers only support for Linux (or WinCE) and the new shop is mainly Linux oriented. Although a some of the dev-team are still FreeBSD at hart. And parts of the system are tested against FreeBSD for avoidance of too much Linux-isms. :) So when I ran into some trouble yesterday, I realized how much FreeBSD has contributed to "painless computing"(tm). And not just only because of the quality of the software, but also because of the support that is offered. And for that I would like to thank, compliment, free-beer-license all the people that made my life trouble free Many many many thanks to all those that make FreeBSD. --WjW ___ 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"
Timeseal works after doing "kldload aout", thanks!
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Thanks for repairing PPPoE
Hi, with tonights cvsup of 5.1-CURRENT my ppp is up and running again. Thanks to who- or whatever did it. Regards, Uli. +---+ |Peter Ulrich Kruppa| | - Wuppertal - | | Germany | +---+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Thanks for the work on devfs and devd!
I just want to thank those who worked on NEWCARD, devfs and devd in V5.0, primarily Dima and imp, I guess. It's been badly needed for a long time, but the advent of USB and Firewire as well as the common use of FreeBSD on laptops had made the lack of dynamic device support a glaring problem in V4. Now that devd is working, things just work--like they should. While this might not be a project the size of the new SMP code, I wanted to let those responsible know that it is really appreciated. I also should thank the NetBSD folks who did the original NEWCARD work, but I don't know where they are. Lots of cool stuff in 5.0, but this one has been annoying me for a LONG time and I know it was really non-trivial to implement some parts of this. Thanks again! I now return you to your regular ration of gripes, some probably from me. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: thanks for heads-up on devfs
On Wed, 22 May 2002, Giorgos Keramidas wrote: > On 2002-05-21 15:03, Rob wrote: > > I am still wondering why MAKEDEV showed up in /usr/src/etc if it is not > > needed? I had an empty directory before I cvsup'd. Thanks, Rob. > > You'll probably need it if you manually disable DEVFS in CURRENT. > However, I don't know if this still works, as I haven't tried it. I still use !DEVFS, since I don't believe in DEVFS. I needed to fix some bitrot in the disk cloning code for finding the root device to work. Initialization of the pty driver causes warnings. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: thanks for heads-up on devfs
On 2002-05-21 15:03, Rob wrote: > I am still wondering why MAKEDEV showed up in /usr/src/etc if it is not > needed? I had an empty directory before I cvsup'd. Thanks, Rob. You'll probably need it if you manually disable DEVFS in CURRENT. However, I don't know if this still works, as I haven't tried it. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
thanks for heads-up on devfs
I am still wondering why MAKEDEV showed up in /usr/src/etc if it is not needed? I had an empty directory before I cvsup'd. Thanks, Rob. -- - The Numeric Python EM Project www.pythonemproject.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Thanks to everyone
Hi all I managed to compile my kernel and include the pcm device with no hang-ups. Thanks for all the responses I got from all of you ! I just refreshed my source tree with the latest STABLE and recompiled it without all the stuff I don't need but including my pcm device --- and it WORKED Now I can play MP3's while coding :) Thanks all Adriaan --- I would change the world, but God would never give me the source code.
thanks
Hey, sorry fr the mini uprising, but I guess you fixed the boot disk issue that I was having because I can now boot 1004 from boot floppies. For some reason my backup kernels couldn't boot the system fully after a cvsup, but I won't get int all that. System's up and running. Gotta make changes to my kernel file so it does SMP right but as someple have said, I will help myself. Thank you. Tony Johnson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: thanks for your nice help ! (was Re: timeout problems ....)
It seems Andreas Klemm wrote: > On Tue, Feb 22, 2000 at 10:15:42PM +0100, Soren Schmidt wrote: > > There are two posibilities, either the cable is bad or the disk is bad. > > Since you could talk to it, and you didn't get ICRC errors, my bet is > > that the particular Maxtor model is just as broken as most of its > > other family memebers :( > > Hmm, too bad. But o.k. actually it's working now and a big > thanks for your kind support !!! You're welcome :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
thanks for your nice help ! (was Re: timeout problems ....)
On Tue, Feb 22, 2000 at 10:15:42PM +0100, Soren Schmidt wrote: > There are two posibilities, either the cable is bad or the disk is bad. > Since you could talk to it, and you didn't get ICRC errors, my bet is > that the particular Maxtor model is just as broken as most of its > other family memebers :( Hmm, too bad. But o.k. actually it's working now and a big thanks for your kind support !!! -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
aic driver (thanks!) and cdrom
Thanks very much for this driver, Luoqi. I am using it in a -current built from October 14 sources, with a new kernel of course. The cdrom produces the following, though: Oct 22 14:14:35 two /kernel: Waiting 15 seconds for SCSI devices to settle Oct 22 14:14:35 two /kernel: (probe2:aic0:0:2:2): ccb 0xc0c90c00 - timed out Oct 22 14:14:35 two /kernel: (probe2:aic0:0:2:2): ccb 0xc0c90c00 - timed out Oct 22 14:14:35 two /kernel: (probe2:aic0:0:2:3): ccb 0xc0c90c00 - timed out Oct 22 14:14:35 two /kernel: (probe2:aic0:0:2:3): ccb 0xc0c90c00 - timed out Oct 22 14:14:35 two /kernel: (probe2:aic0:0:2:4): ccb 0xc0c90c00 - timed out Oct 22 14:14:35 two /kernel: (probe2:aic0:0:2:4): ccb 0xc0c90c00 - timed out Oct 22 14:14:35 two /kernel: (probe2:aic0:0:2:5): ccb 0xc0c90c00 - timed out Oct 22 14:14:35 two /kernel: (probe2:aic0:0:2:5): ccb 0xc0c90c00 - timed out Oct 22 14:14:35 two /kernel: Creating DISK da0 Oct 22 14:14:35 two /kernel: Creating DISK da1 Oct 22 14:14:35 two /kernel: Creating DISK cd0 Oct 22 14:14:35 two /kernel: changing root device to da1s2a Oct 22 14:14:35 two /kernel: da0 at aic0 bus 0 target 0 lun 0 Oct 22 14:14:35 two /kernel: da0: Fixed Direct Access SCSI-2 device Oct 22 14:14:35 two /kernel: da0: 5.000MB/s transfers (5.000MHz, offset 8) Oct 22 14:14:35 two /kernel: da0: 4345MB (8899737 512 byte sectors: 64H 32S/T 4345C) Oct 22 14:14:35 two /kernel: da1 at aic0 bus 0 target 1 lun 0 Oct 22 14:14:35 two /kernel: da1: Fixed Direct Access SCSI-2 device Oct 22 14:14:35 two /kernel: da1: 5.000MB/s transfers (5.000MHz, offset 8) Oct 22 14:14:35 two /kernel: da1: 2069MB (4238640 512 byte sectors: 64H 32S/T 2069C) Oct 22 14:14:35 two /kernel: (cd0:aic0:0:2:0): got CAM status 0x20c Oct 22 14:14:35 two /kernel: (cd0:aic0:0:2:0): fatal error, failed to attach to device Oct 22 14:14:35 two /kernel: (cd0:aic0:0:2:0): lost device Oct 22 14:14:35 two /kernel: (cd0:aic0:0:2:0): removing device entry Annelise To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fergot to say thanks
For the person who helped me with my xl driver kernel compile, thanks. I am alittle pine expunge happy! Arthur H. Johnson II http://www.linuxberg.com Linuxberg Manager [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Thanks, sound is fixed
On Wed, 5 May 1999, Vallo Kallaste wrote: > I just want to let know that sound works again for my workstation. > Thanks Doug, it was quite annoying to have icecast running but not to > hear anything I broadcast :-) Sorry the fix took so long :-). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Thanks, sound is fixed
I just want to let know that sound works again for my workstation. Thanks Doug, it was quite annoying to have icecast running but not to hear anything I broadcast :-) -- Vallo Kallaste va...@matti.ee To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
someone fixed CPU time bug, thanks.
SMP on -current would lose the WCPU and CPU times after a while in top's output, this seems to be fixed on my machine/mobo with the latest source. Asus PD2 afaik dual 400mhz. thanks guys, great work! -Alfred To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
