Problem:
After connecting with my AE3000, when the networks start to get some load (a couple of web pages), i get a kernel panic. I have no idea why.
This is using NetworkManager, not ifup and all that stuff - tried that for several hours yesterday, but wpa_supplicant kept crashing. I want to get this to work with the kde applet network manager.
History:
At first, the dongle didnt work at all. I found a fix for this from this handy site: Geek Scribble: Cisco Linksys AE3000 WiFi USB Dongle and Linux Driver Installation
This works pretty well. After compiling and installing the correct driver - I get the dongle to start blinking and I can search for wireless. But when I connect; kernel panic.
Same computer, same dongle; all the same. Installed Ubuntu and the same driver. NO problem. Both 64-bit. Why is that? I cant figure out what the reason could be.
Things I have tried:
Upgrading the kernel to 3.5.3 - no luck
Installing a different (newer-ish) version of the driver - no luck
Connecting with wpa_supplicant and all that stuff - no luck
Feels like I have tried a lot more - but cant remember any of it if thats the case xD
Anyways, I hope I have provied enough information for now. If you need any output my terminal and/or logs - let me know!
On 09/12/2012 07:56 AM, bjaanes wrote:
>
> Okey, mail sent =)
>
> In the meantime - if anyone have any tips or possible solutions, feel
> free to post them =)
>
>
> Btw, I think you meant FAE@ralinktech.com, beacause the other address
> didnt deliver.
> Anyways, thanks thus far.
Kernel panics are the hardest to debug as they do not leave any records in the
logs. The only way to handle them without setting up a serial console is to
switch to virtual terminal 10 (CTRL-ALT-F10) before the crash occurs. The
backtrace is logged to that screen where you can photograph it, or write down
the contents.
I think I remember some mail about the RT3573 in the wireless developers ML, but
I did not save it, and there are no patches in the current kernel. I suggest you
write to linux-wireless@vger.kernel.org and describe your problem. Include the
output of lsusb for the device. If you can capture the dump from the kernel
panic, even better.
On 12/05/2012 07:06 PM, ryanbach wrote:
>
> lwfinger;2486429 Wrote:
>> On 09/12/2012 07:56 AM, bjaanes wrote:
>>>
>>> Okey, mail sent =)
>>>
>>> In the meantime - if anyone have any tips or possible solutions, feel
>>> free to post them =)
>>>
>>>
>>> Btw, I think you meant FAE@ralinktech.com, beacause the other address
>>> didnt deliver.
>>> Anyways, thanks thus far.
>>
>> Kernel panics are the hardest to debug as they do not leave any records
>> in the
>> logs. The only way to handle them without setting up a serial console
>> is to
>> switch to virtual terminal 10 (CTRL-ALT-F10) before the crash occurs.
>> The
>> backtrace is logged to that screen where you can photograph it, or
>> write down
>> the contents.
>>
>> I think I remember some mail about the RT3573 in the wireless
>> developers ML, but
>> I did not save it, and there are no patches in the current kernel. I
>> suggest you
>> write to linux-wireless@vger.kernel.org and describe your problem.
>> Include the
>> output of lsusb for the device. If you can capture the dump from the
>> kernel
>> panic, even better.
> With lsusb I get: ID 13b1:003b Linksys
>
> I have the same issue with my Cisco N900 wifi usb aka. AE3000. Is there
> an updated driver somewhere?
If you are saying that your Cisco N900 has ID 13b1:003b and it is causing a
kernel panic, then you must be using the vendor’s driver. In the latest wireless
drivers, there are no devices with that ID, thus nothing internal is available.
Obviously, kernel developers cannot be responsible for drivers from the vendor.
If you catch the panic on the CTRL-ALT-F10 screen, we might be able to debug it
a little. Without such panic info, we can do nothing.
When the driver builds, are there warnings? Sometimes these indicate a 32-bit
driver that will build, but not run, on a 64-bit system.
Option 2, rt2800usb the default module for majority of Ralink chipsets, that comes included with the kernel does not support RT3573 (the chipset used in Cisco AE3000) chipsets. Why? rt3573 is a 3x3 chipset, a relatively new one to linux kernel, and development work is on-going.