BWN State with BCM4321

2011-03-17 Thread Domagoj S.
I need an insight, regarding my wifi card:

I've found this on maillist freebsd-current:
http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014782.html

Which motivated me, to directly mail, writer of driver.


ME:
Hello,

How long until bwn(4) will work with: Broadcom 432AGN WiFi mini PCI-Express
That is BCM4321

Currently I'm loosing my patience with: (I'm Seeker)
http://forums.freebsd.org/showthread.php?t=9204page=6

If you have some code for me to try?
I use amd64 8.2 RC2



No plan to add a code for PHY-N drivers.
It'll be happened by others not me.  :-)

regards,
Weongyo Jeong

ME:
Can I hava a contact of those others?
;)

ME:
Listen, after having a thought, I really thing that you shoud finalize this
by adding a code for PHY-N drivers, thus making even my card able to work
nativelly on FreeBSD.
Because you already know that code, from inside out.
New developer would first need to familiarize itself with all that code,
before he would even start to code on PHY-N drivers.
If you do it, it would be magnitudes faster and I also promise I will be
actievlly available, to constantly test your code, on my laptop.

If you add a code for PHY-N drivers, then I'll completelly ditch WinXP and
transfer to FreeBSD.
As ndis is unstable, I still must use WinXP via dulaboot, so I could write
you this email.

So, you are not just adding a code for PHY-N drivers, but you are also
adding a new user to FreeBSD.
;)

Think about it ...
---


No reply ...
So ..., what is going on with it?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: intel i5 - core? or core2?

2010-08-23 Thread Domagoj S.
On Sat, Aug 21, 2010 at 6:25 PM, Anonymous swel...@gmail.com wrote:
 Domagoj S. rank1see...@gmail.com writes:

 8.1 RELEASE  32bit

 # gcc --version
 gcc (GCC) 4.2.1 20070719  [FreeBSD]

 As per:  http://gcc.gnu.org/gcc-4.2/changes.html
 core2 is supported

 It's not! `core' and `core2' for -mtune/-march introduced since gcc43.

Ups!
I've been confusing FreeBSD's 'CPUTYPE' with gcc's '-march='


 BTW, while clang in base (on /head) supports -march=core2 it's still
 better to stick to -march=native, e.g. on my box

  CPU: Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz (3177.07-MHz K8-class 
 CPU)

 `native' on clang implies `penryn', not a `core2'. While `native' on
 gcc45 implies `core2' + extra cflags[1].

 [1] -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param 
 l1-cache-line-size=64 --param l2-cache-size=6144


I see..., so I should always go against FBSD devs and ensure that
gcc's arg '-march=' is always populated by value 'native'?
That is, gcc should alone determine CPU? Not a human user and then
setting discovered CPU type in CPUTYPE?


 You can populate MACHINE_CPU directly, e.g.

  CPUTYPE ?= native
  MACHINE_CPU != echo ${MACHINE_ARCH}; ${CC} -E -dM -v -march=${CPUTYPE} - 
 /dev/null 21 \
        | awk '/SSE|MMX/  !/MATH/ { FS=__; gsub(_,.,$$2); print 
 tolower($$2) }'
  MACHINE_CPU += i486 i586 i686

 Note sure how well it'll work for cross-arch compilation, though.

Setting CPUTYPE will populate MACHINE_CPU.
Then I can ensure gcc's arg '-march=native' by setting:
CFLAGS=-O2 -pipe -march=native

But CPUTYPE will also append it's own '-march=', so to stop it:
NO_CPU_CFLAGS=yes

I've also saw recommendation to add:
COPTFLAGS=-O2 -pipe -march=native
NO_CPU_COPTFLAGS=yes

But I didn't see that CPUTYPE, has ever set COPTFLAGS?


So now I am totally confused with all this options?
What is the right way?


 CPUTYPE?=native is nowhere mentioned in FreeBSD

 That cruft in bsd.cpu.mk was written in pre-gcc4 days, i.e. when it
 didn't support -march=native. Besides, if not maintained to accommodate
 for newer gcc's from ports those aliases are more harmful than
 useful. And not much code uses MACHINE_CPU in base anyway, only
 libcrypto and libz.


So if I decide to use a latest compiler from ports, I MUST avoid usage
of CPUTYPE?

Finally, should I use latest gcc compiler from ports, to build world 
kernel, with:
CFLAGS=-O2 -pipe -march=native
COPTFLAGS=-O2 -pipe -march=native
MACHINE_CPU=???


And a, regarding speed, please in percentage and taking regular binary
install from .iso, as a speed of value 100%, to be compared against.
What kind of gain, is compared to compilation from source:
a) Without any variables set in /etc/make.conf or passed on CMD
b) Only CPUTYPE var set, as officially recommended
c) Appending CFLAGS, NO_CPU_CFLAGS ... to b)
d) Using latest gcc from ports
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: intel i5 - core? or core2?

2010-08-21 Thread Domagoj S.
8.1 RELEASE  32bit

# gcc --version
gcc (GCC) 4.2.1 20070719  [FreeBSD]

As per:  http://gcc.gnu.org/gcc-4.2/changes.html
core2 is supported

Setting CPUTYPE(for i386) to:  nocona, core or core2, will at
the end, ALWAYS set CPUTYPE to:  prescott, which again results in
set:
MACHINE_CPU = sse3 sse2 sse i686 mmx i586 i486 i386

CPUTYPE?=native is nowhere mentioned in FreeBSD
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


ls, mount point aware

2010-07-30 Thread Domagoj S.
As I can see, more and more base apps, are aware of mount points.
I.e; In 8.1, chgrp(1), chown(8) and cp(1) now have an -x flag.

And what about human users?

'ls' command, should in it's long list of directories, show something like:
Hey, this directory, is also a mount point.

One letter flag?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: loader prompt: list / on other device

2010-06-23 Thread Domagoj S.
2010/6/23 Eugene Grosbein eu...@grosbein.pp.ru:
 On 23.06.2010 23:03, rank1see...@gmail.com wrote:
 I've escaped to loader prompt:
 Current device is disk0s3a, from which this loader is running.

 My USB stick is device1 and device1s2a is UFS /, on which I would like to
 reach some file or simply list directory.

 Syntax?

 I guess, you have to change 'currdev' variable to point to right diskX

 Eugene Grosbein

Thanks Eugene!
It worked. ;)

I've booted ad4s3a and escaped to loader prompt.
currdev was disk0s3a
USB stick was disk1s2a, which mounted, appears as da0s2a

I used more /etc/fstab in order to get hostname
HDD_hostanme

Then at loader prompt:
set currdev=disk1s2a

Then again, I used more /etc/fstab in order to get hostname:
USB_hostanme


On Wed, Jun 23, 2010 at 6:45 PM,  m...@freebsd.org wrote:
 On Wed, Jun 23, 2010 at 9:03 AM,  rank1see...@gmail.com wrote:
 I've escaped to loader prompt:
 Current device is disk0s3a, from which this loader is running.

 My USB stick is device1 and device1s2a is UFS /, on which I would like to
 reach some file or simply list directory.

 IIRC, there is no way to do this (but my memory is based on stable/7).
  I extended some Isilon stuff to add a 'bootdev' command to the loader
 that would allow for selecting alternate boot disks.  I can see about
 dusting that off and making a patch against CURRENT, if there is no
 current way to do what you ask.

 Cheers,
 matthew

Well, looks like it is working on 8.0 RELEASE.


On Wed, Jun 23, 2010 at 7:03 PM, Andrew Duane adu...@juniper.net wrote:
 You *should*  be able to use device1s2a:/ as a syntax, but I noticed a bug in 
 our old loader code that parses devicenames like that where it wouldn't work 
 correctly with unit numbers. I don't know if that bug is still around, but 
 setting currdev did work around it.

 /Andrew

Thx!
I'll try it...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Custom USB layout sysinstall (Starting FIXIT)

2010-05-27 Thread Domagoj S.
On Fri, May 28, 2010 at 1:02 AM, Garrett Cooper yanef...@gmail.com wrote:
 On Thu, May 27, 2010 at 3:53 PM, none none rank1see...@gmail.com wrote:
 Still no answer?

 Hey, there is also a thread:
 http://forums.freebsd.org/showthread.php?t=14059

 Hate to say but you're doing something unsupported, so unless you walk
 through the process by yourself to figure out where things are going
 wrong, I'm not sure others have the time to help you in this endeavor.

I did found and posted code snippet that is responsible for detecting devices.
But I have no C lang knowledge needed to do any coding.
I know PHP and JS, ..., so have been observing patterns and echo-ed
text/strings to terminal

 sysinstall(8) assumes a custom environment and setup; trying to
 unravel it would be painful, so I don't suggest doing that.

sysinstall(8) expects precise enviroment.
Anything deviating from it's hardcoded path is being ignored.

 If you're going to roll your own solution you might as well roll the entire
 thing from scratch.

 Thanks,
 -Garrett

My solution is to get rid of sysinstall.
Idealy, if sysinstall would be skipped upon boot and Fixit# started immediately

I have a blueprint in my head, with beginning, that I am hammering
here, but without knowledge to code it.


 With respect to your Still no answer message I'm not sure what
 you're expecting for an answer.  You answer yourself above.

I expected a patch, an .diff, which I would apply to
/usr/src/usr.sbin/sysinstall/...
And finally recompile it.

 The customizations you're doing that you refer to as B do indeed
 confuse sysinstall's disk recognition semantics.  As part of
 your customizations you'll need to adjust sysinstall's disk
 recognition semantics to understand the layout you are setting
 up.  I'm not quite sure what else you are expecting.

Someone, to do that for me and handed over, to me, on a silver plate.
I am not a FreeBSD dev. Hell, I've just entered this list and this is
my first topic.,

  I can't think of some easy fix that would get you past the problem you
 are experiencing without some hacking done to sysinstall.  I'm
 also not sure if that sort of hacking would be suitable for
 the general case (what works now).

 - --
Ken Smith

I think it would be, as it would just look in a extended way for devices.
Thus, covering old ones and satisfying my needs/aims


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