Tuesday, September 27, 2011
Monday, September 26, 2011
Tuesday, September 20, 2011
Saturday, September 17, 2011
Top 10 USB drive / pen drive related problems and fixes:
http://www.troublefixers.com/solutions-to-top-10-usb-pen-drive-problems/
Friday, September 16, 2011
FTP WINDOWS command line
@echo off
echo user anonymous> ftpcmd.dat
echo anon@localhost>> ftpcmd.dat
echo bin>> ftpcmd.dat
echo get %1>> ftpcmd.dat
echo quit>> ftpcmd.dat
ftp -n -s:ftpcmd.dat 192.168.33.119
del ftpcmd.dat
Thursday, September 15, 2011
Wifi Study Materials
1)802.11 Wireless Networks, The Definitive Guide, 2nd Ed.chm
2)802.11n.pdf
3)Next Generation WirelessLANs
Throughput,Robustness,andReliabilityin802.11n
ELDAD PERAHIA AND ROBERT STACEY
4)WiFi_P2P_Technical_Specification_v1.00.pdf
5)WMM (including WMMTM Power Save) Specification
2)802.11n.pdf
3)Next Generation WirelessLANs
Throughput,Robustness,andReliabilityin802.11n
ELDAD PERAHIA AND ROBERT STACEY
4)WiFi_P2P_Technical_Specification_v1.00.pdf
5)WMM (including WMMTM Power Save) Specification
Monday, September 12, 2011
How to use the latest 802.11 drivers and stack with Linux
http://nilvec.com/how-to-use-the-latest-802-11-drivers-and-stack-with-linux/
How to use the latest 802.11 drivers and stack with Linux
There might be several reasons why the wireless drivers from your distro don’t fit the bill. You purchased a new wifi card which doesn’t have a driver in the kernel of your Linux system, or you would like to play with some cool new feature or just to make sure you have the latest and greatest, cutting edge 802.11 software.
Thanks to the work of the Linux wireless developers it is now possible to do that without upgrading your kernel. Using a compatibility layer you can compile and install the latest drivers and the 802.11 stack, and use it with your current kernel (that is, if you have a relatively recent kernel — if you have 2.6.24 or anything more recent, you’re good to go).
To use bleeding edge drivers, first make sure your kernel headers package is installed. Then fetch the necessary git trees:
mkdir compat-wireless && cd compat-wireless
git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git clone git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat.git
git clone git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6.git
The linux-next git tree contains the code for the next kernel release, and 802.11 updates are pulled into it on a regular basis. The compat and compat-wireless-2.6 trees implement the necessary compatibility layer, thus making it possible to use the wireless subsystem from linux-next with your kernel. You can also use your git trees to follow development, and keep your wireless drivers up to date: just pull from the remote repositories when you’d like to update. However, the linux-next repository is rebased on a regular basis, so you may want to check out the daily tag instead of pulling.
You can use the compat-wireless-2.6 directory to actually build the wireless subsystem:
cd compat-wireless-2.6
Specify where your newly fetched kernel tree and the compat tree are:
export GIT_TREE=`pwd`/../linux-next/
export GIT_COMPAT_TREE=`pwd`/../compat/
Then refresh compat-wireless-2.6 with the contents of your git trees:
./scripts/admin-refresh.sh
You can also select just a specific driver or group of drivers, e.g. if you only need the ath5k driver:
./scripts/driver-select ath5k
And that’s it, everything should be ready for the build.
make
sudo make install
Your newly built modules will go into the updates folder inside your kernel module directory. Reboot your box (or use the scripts supplied with compat-wireless-2.6 to reload any drivers).
Saturday, September 10, 2011
Thursday, September 1, 2011
Size of the linux library
http://groups.google.com/group/gnu.gcc.help/browse_thread/thread/275b49bca43300be?pli=1
Hi Guys!
I have such library:
$ size -A lib.so.1 :
section size addr
.hash 172504 180
.dynsym 427408 172684
.dynstr 248347 600092
.gnu.version 53426 848440
.gnu.version_r 144 901868
.rel.dyn 19750456 902012
.rel.plt 336 20652468
.init 23 20652804
.plt 688 20652828
.text 135412 20653520
.fini 28 20788932
.rodata 4215968 20788960
.eh_frame 4 25004928
.ctors 8 25009028
.dtors 8 25009036
.jcr 4 25009044
.data.rel.ro 15683552 25009056
.dynamic 240 40692608
.got 352 40692848
.got.plt 180 40693200
.data 136 40693380
.bss 108 40693536
.comment 5220 0
Total 40694552
I've noticed .rel.dyn section is pretty big (almost 20M).What is
the possible reason of that size and how to reduce it?
Wow! You must have a *lot* of external data and constants referenced
from that library.
readelf -r lib.so.1
For .data.rel.ro, do this:
objdump -T lib.so.1 | grep data.rel.ro
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Hi Guys!
I have such library:
$ size -A lib.so.1 :
section size addr
.hash 172504 180
.dynsym 427408 172684
.dynstr 248347 600092
.gnu.version 53426 848440
.gnu.version_r 144 901868
.rel.dyn 19750456 902012
.rel.plt 336 20652468
.init 23 20652804
.plt 688 20652828
.text 135412 20653520
.fini 28 20788932
.rodata 4215968 20788960
.eh_frame 4 25004928
.ctors 8 25009028
.dtors 8 25009036
.jcr 4 25009044
.data.rel.ro 15683552 25009056
.dynamic 240 40692608
.got 352 40692848
.got.plt 180 40693200
.data 136 40693380
.bss 108 40693536
.comment 5220 0
Total 40694552
I've noticed .rel.dyn section is pretty big (almost 20M).What is
the possible reason of that size and how to reduce it?
Wow! You must have a *lot* of external data and constants referenced
from that library.
> I've noticed .rel.dyn section is pretty big (almost 20M).What is
> the possible reason of that size and how to reduce it?
You can see what goes into rel.dyn with: > the possible reason of that size and how to reduce it?
readelf -r lib.so.1
For .data.rel.ro, do this:
objdump -T lib.so.1 | grep data.rel.ro
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
![]() |
> You can see what goes into rel.dyn with: That's really interesting: > readelf -r lib.so.1 I have 2470084 entries like that: 013b572f 00000008 R_386_RELATIVE 013b5738 00000008 R_386_RELATIVE 013b574b 00000008 R_386_RELATIVE 013b5768 00000008 R_386_RELATIVE 013b5776 00000008 R_386_RELATIVE I've googled that: "The dummy R_386_RELATIVE relocations are used to adjust the required absolute addresses at run time." M. |
![]() |
mkaszc...@gmail.com writes: You probably didn't look far enough into the list to find >> You can see what goes into rel.dyn with: >> readelf -r lib.so.1 > That's really interesting: > I have 2470084 entries like that: > 013b572f 00000008 R_386_RELATIVE > 013b5738 00000008 R_386_RELATIVE > 013b574b 00000008 R_386_RELATIVE > 013b5768 00000008 R_386_RELATIVE > 013b5776 00000008 R_386_RELATIVE "meaningful" entries. Try 'readelf -r lib.so.1 | grep 013b572f' > I've googled that: That was possibly written by someone clueless, or else you took > "The dummy R_386_RELATIVE relocations are used to adjust the required > absolute addresses at run time." the statement out of context. There is nothing "dummy" about R_386_RELATIVE relocations. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. |