The bleeding edge...

It seems amazing to me how close I live to the bleeding edge.

So I got an iBurst connection. iBurst is a 1Mbps wireless connection to the Internet. The idea was that I would connect this to a Debian Linux box that would act as a gateway to other machines in my house. To keep my newly renovated house wire free, I bought an SMC2802W 54Mbps wireless card. I was going to get the DLink Atheros chipset based card, but then saw the amount of development history for Prism chipset cards. I also saw that the newer 2.6 linux kernels provided native support for the Prism chipset. So I thought it was going to be a case of plugging in the card and WhaLah! It never is...

A good summary of wireless networking with Linux is provided here.

First of all, I had hassles compiling my 2.6.11.6 kernel. I'll post my summary of how and some good links in another post.

After compiling the kernel, I could see the card using lspci. Using iwconfig, it showed the card (meaning that the Prism54 module had loaded). But nothing would change the card's state from "NOT READY!"

Then I discovered that there are various verions of the Prism54 based cards. The prism54.org site shows development going waaaay back (which is why I thought I was safe). But there is discussion about cards made in Taiwan working and those made in China not.

But I dug a little further. I discovered that not only do you need to have the driver for the prism chipset working, it also relies on the kernel being configured for hotplugging PCI cards.

The reason you need hotplugging enabled is that firmware updates need to be placed in the correct directory for upload when the card initialises. So you need to get the firmware.

This above process is nicely summarised on the prism54.org wiki.

Of course it didn't work.

Recent discussion on the prism54 mailing list (not yet picked up by Google) shows that resetting the card on a windows machine and then inserting back into the Linux box works. The final part of the discussion can be followed on this thread.

So after much hassle related to removing the card, getting it going under windows and then reinserting into my Linux box.... nothing.

So then I went to the prism54.org driver pages and looked for the latest one. Got the CVS download here. But more important than that, I noticed the readme. Going through the kernel setting requirements, I noticed quite a few settings out of kilter with my kernel. SO I changed those, recompiled and rebooted...

And I got a ton of errors on boot up along the lines of:

Apr 13 11:22:39 localhost kernel: evbug.c: Event. Dev: isa0060/serio0/input0, Type: 1, Code: 22, Value: 1
Apr 13 11:22:39 localhost kernel: evbug.c: Event. Dev: isa0060/serio0/input0, Type: 0, Code: 0, Value: 0
Apr 13 11:22:39 localhost kernel: evbug.c: Event. Dev: isa0060/serio0/input0, Type: 4, Code: 4, Value: 22


Bolllllloooocks!!! Searching for this, I found lots describing this as a kernel 2.6 bug and workarounds involving hiding the evbug module. Searching through the .config file however, I located the offending module under "Input device / Userland interfaces" - Event Debugging, and turned this off.

That all worked and with my finely tuned 2.6.11.10 running I compiled the latest prism 54 driver. Alas. Many compile errors. The one that held things up was

error: too many arguments to function `pci_save_state'

On advise from this site, I made the following changes in the islpci_hotplug.c file:

pci_save_state(pdev,handle->pci_state);
to
pci_save_state(pdev);

AND

pci_restore_state(pdev,handle->pci_state); or pci_restore_state(pdev,NULL);
to:
pci_restore_state(pdev);

Well that did the trick - it compiled. But after compiling the Prism driver failed with the following message:

prism54: Unknown symbol pci_dma_sync_single.

SO I think this has all been in vain. Much effort and time I do not have.

But I post this here, knowing others on this path will Google here and read this either before wasting their time, or commenting and leaving a working answer :)