Broadcom Wireless and Linux

Here is the “straightforward” way

see (http://ndiswrapper.sourceforge.net/mediawiki/index.php)
for more info.

  • Download this windows driver
  • unzip the file you downloaded.
  • run “ndiswrapper -i FILE” on any .inf files you downloaded.
  • run “ndiswrapper -l” and it should say “driver present hardware present” if not, there is a problem.

type:

depmod -a
modprobe ndiswrapper

try “ethq wlan0 scan” if it worked, this should do something.

Troubleshooting

With Ubuntu for some reason it loads a bad driver you should blacklist. This issue is covered a bit better here: http://ubuntuforums.org/showthread.php?t=285809

Here’s another issue with Edgy. I got this email from a friend. My Wireless stopped working because the latest version was bad. Probably not an issue now, but if you’re having problems you may want to give it a shot.

hey rich
Speaking of the devil, yeah, i just figured that out like 3 minutes ago. From what i can tell, it seems like the new version of ndiswrapper (like 1.7?) screws things up. Or something. So i just downloaded and installed an older version of ndiswrapper. I got ndwiswrapper-1.27. i just downloaded and extracted the file, didn’t use apt-get. after that:

1. cd to the extracted directory of ndiswrapper-1.27
2. sudo make uninstall (ur supposed to do this until there are no errors…)
3. sudo make
4. sudo make install
5. then just do sudo ndiswrapper -i filename.inf for your driver.

Now mine works again, yay. The problem i had thought was i didn’t have the kernel headers so it wouldn’t compile ndiswrapper. i (eventually) did a sudo apt-get install linux-headers-2.6.17-10-386. Now if you’re running a different version of the kernel, then replace that last string with ur version. the command to get ur exact kernel is “uname -r”. so yeah….do that, then do the make uninstall, make, make install, and then it should work again. I don’t have the link for that 1.27 version download, but google should find it pretty quick.

So in summary, the best solution is probably to get rid of piece of shit broadcom chips :)

Hanging mount (not the way you like it)

Symptom: trying

$ mount -t nfs 10.0.0.1:/whatever /whatever

is just hanging there.

Troubleshooting: rpcinfo -p servername is fast and responsive. A lot of times when rpc fails nfs will fall on a backup protocol that is fairly slow. With rpcinfo -p, you can rule this out as being your problem.

portmapper is running. According to lord google, this has been the cause of the problem many a time. Not my problem though.

The server logs don’t say crapola.

What do you do?

Solution: You may just have bad syntax. Try

$ mount -t nfs 10.0.0.1:/whatever/ /whatever/

Yes, this took me hours to figure out. Stupid slash.

From #islug (I kept the last bit because I like to talk about fscking whenever I get a chance).

<mop> Have you ever spent all day stressed out about a problem, then you figure out that it’s all just because you left a trailing front slash?
<mop> Reminds me of my first days programming and missing semi-colons, the bastards.
<twinprism> yes. :)
<TomHung> echo $iknowyourfeeling
<bradmw> mop: what language?
<mop> Today: just mounting an nfs file share (around 2 hours debugging to find out its because I mounted /whatever instead of /whatever/)
<mop> Back in the day: C
<bradmw> does linux have a scandisk type program to check floppies for bad sectors?
<mop> you can fsck a floppy
<mop> just like an apple pie
* TomHung <= fsck up
<TomHung> FSCK U & TH3 HORSE U R0DE IN ON
<bradmw> let me unmount my sheep first
<mop> common mistake. umount.
<mop> ;)
<TomHung> mount /dev/usb /home/sheep

Believe it or not I’ve done basically the same thing with grep -R…

Zombie Killer

This morning I got to thinking.  What happens if parents die before their kids?  The world could be flooded with zombies.

Some background.  Unix allows a child to get the PID of its parent or the execution state of its children.  For example, a parent can spawn a child to complete some process, and then wait to check when the child has terminated.  If the child is dead, it’s termination code will tell the parent whether or not the task was completed succesfully.

So Anyway, Unix kernels can’t discard data in the process descriptor fields right after a process terminates.  They can only kill themselves completely after their parent has issued a wait()-like call (seen whether their task was completed).  This is why zombies were introduced: although the process is dead, it must live until the parent is notified of it’s death.

So if a parent dies to leave orphaned children, the world could theoretically be flooded with these zombies, since there are no parents to issue wait()-like system calls.  This problem is solved by forcing all orphans to become children of Init.  In this way, Init will destroy zombies while checking for the termination of one of its legitimate children through wait()-like calls.

The release_task() function detaches the last data structures from the descriptor table – or “blows their brains out” if you will.

Obviously, everything I’m saying is not about processes, but about real zombies and an unsung hero named init.

Follow

Get every new post delivered to your Inbox.