Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes in 8192cu stopped ability to scan wifi-networks #850

Closed
mr-berndt opened this issue Feb 24, 2015 · 6 comments
Closed

Changes in 8192cu stopped ability to scan wifi-networks #850

mr-berndt opened this issue Feb 24, 2015 · 6 comments

Comments

@mr-berndt
Copy link

Hi,

trying to upgrade my system to run on the new raspberry 2, I ran into trouble with my wireless-dongle EDIMAX EW-7811UN (7392:7811). It uses the 8192cu module and after compiling the new 3.18.7 kernel, the module loads but tells me that my wifi-dongle doesn't support scanning of the networks, which it did before and without I cannot work.

Out of curiousity I installed raspian (have a small self-built busybox system otherwise) and found the 8192cu module to enable scanning there. Modinfo told me, that the module used in that particular 3.18.7 kernel was from Realtek itself, modinfo on my 3.18.7 kernel from github doesn't.

Following issue #755 #755 I tried including the realtek-source right in my (cross-compiled) kernel-source-tree but ended up having the mentioned proc-issue upon compilation. Looking for the CONFIG_PROC_DEBUG portion in my kernel .config, I found this option to be non-existant (anymore?), so this is where I give up and now ask for help here..

Which driver exactly IS included in 3.18 right now and why has it changed from 3.16 where it was working like a charm? What can I do to get a 8192cu module again, that supports scanning of it's surrounding?

Help would of course be very appreciated!
Best regards
Nico

@popcornmix
Copy link
Collaborator

The upstream 8192cu is widely regarded as unusable (see #755)
So, we include the out-of-tree Realtek driver.
Raspbian uses the rpi-3.18.y tree and is built with config from:

make ARCH=arm bcm2709_defconfig

which will be using the out-of-tree Realtek driver.

I'd suggest you build the default tree with default config.
I'm afraid I can't offer support for the known buggy upstream 8192cu driver.

@mr-berndt
Copy link
Author

I'm afraid, I don't understand. The driver included in the regular 3.18 kernel-source from github breaks scanning for me, so I would consider this the broken driver, or not? I failed compilation when I tried to include the Realtek-driver.

So this leaves me with a not fully-functioning driver in the regular kernel-sources from github and a non-compiling driver from Realtek.

Which of these drivers is the "upstream"-driver and which can you support? I'm confused here, sorry..

@mr-berndt
Copy link
Author

OK, maybe I should have read your post more careful, sorry. So I understand that the driver included in 3.18 IS the Realtek-driver. Now I don't understand why scanning doesn't work, when it does work using stock raspbian with 3.18, since in raspbian modinfo tells me, that the driver is the one from Realtek and should be no different from the driver I get compiling 3.18 myself.

@popcornmix
Copy link
Collaborator

Are you building with our bcm2709_defconfig? I'd start with that and then make changes.

@mr-berndt
Copy link
Author

I have a very small 3.16 self-configured kernel with just 5 or 6 modules. Oldconfig gave me trouble and so I went from bcm2709_defconfig an threw out a lot of drivers which I knew were external hardware, so actually I should be good. I will try how the full bcm2709_defconfig behaves and report back..

@mr-berndt
Copy link
Author

OK, bcm2709_defconfig really did the trick, I can scan again!

A new problem came up, though, I am getting a "unable to handle kernel paging request at address ffffffff" but I will have to fix that myself, it is not happening with the same kernel on raspbian, so there must be some issue with my system.

Thanks for the help!

pfpacket pushed a commit to pfpacket/linux-rpi-rust that referenced this issue Apr 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants