Note that this card is not listed as working on the RT2x00 driver site . I haven't tested it on the current kernel's 2800 driver, but it didn't work with the 2800 driver in 3.3 and 3.4. Perhaps re-checking that is the next step.
Assuming rt2x00 still doesn't support this card, the driver I'm using is the official RT8070 /RT3070 /RT3370 /RT5370 /RT5372 USB driver provided by MediaTek. This is the offending driver, which functions perfectly for kernels <= 3.3, and causes kernel panics on network traffic* in 3.4 and above.
* No kernel panic with a simple ping, kernel panic usually occurs on HTTP traffic for me. I haven't done extensive enough testing to say whether this is HTTP specifically, TCP specifically, etc... I'm usually too busy swearing at a screen full of errors.
After first downgrading kernel in July last year, I eventually decided to switch to the linux-lts package and wait until this issue resolves itself. Long term support is running 3.0, which these drivers are still compatible with.
There's been no change to this problem in the kernel versions since then, and it doesn't seem realistic for all users of these cards to continue using long term support kernels forever. Where do we go from here?
It seems that the bug needs to be tracked down in the 5370sta sources and fixed.
I'm not exactly qualified to do this myself so I went looking to see if there's an upstream where bug reports can be filed.
This leads me to the present canonical location for the driver download, which claims that mediatek is "very active in the linux community".
Available sources are still the 2011 version which is causing the problem.
I can't find any references to a bug tracker or any ability to communicate with upstream.
Has anybody else with this problem had more luck?
]]>r8169 0000:03:00.0: eth0: link up
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
When issuing a ping -t from my desktop to the NAS system, it barely stayed online for 1 minute before faceplanting again. When there is no network access it stays online longer, mostly until my ESX system is starting to access its NFS datastores.
]]>Thank you Kiirani, I added the linux-header package as well
sudo pacman -U /var/cache/pacman/pkg/nvidia-295.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/nvidia-utils-295.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/linux-3.3.7-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/linux-headers-3.3.7-1-x86_64.pkg.tar.xz
But still I get:
[christer@Arch ~]$ uname -r
3.4.4-2-ARCHRegards
Have you rebooted to the new kernel?
]]>sudo pacman -U /var/cache/pacman/pkg/nvidia-295.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/nvidia-utils-295.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/linux-3.3.7-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/linux-headers-3.3.7-1-x86_64.pkg.tar.xz
But still I get:
[christer@Arch ~]$ uname -r
3.4.4-2-ARCH
Regards
]]>I manage (almost) to downgrade to 3.3 kernel but after reboot it looks like 3.4 is still loaded.
uname -r
Output: 3.4.4-2-ARCH
I did:
sudo pacman -U /var/cache/pacman/pkg/nvidia-295.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/nvidia-utils-295.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/linux-3.3.7-1-x86_64.pkg.tar.xz
You'll need to get the appropriate linux-headers package as well. Maybe that's the problem?
I also run:
grub-mkconfig -o /boot/grub/grub.cfg
To regenerate grub2 (I dont know it it is nessesary).
Completely unnecessary.
]]>uname -r
Output: 3.4.4-2-ARCH
I did:
sudo pacman -U /var/cache/pacman/pkg/nvidia-295.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/nvidia-utils-295.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/linux-3.3.7-1-x86_64.pkg.tar.xz
If I run againe I get:
[christer@Arch Archlinux+++]$ sudo pacman -U /var/cache/pacman/pkg/nvidia-295.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/nvidia-utils-295.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/linux-3.3.7-1-x86_64.pkg.tar.xz
Password:
loading packages...
warning: nvidia-295.59-1 is up to date -- reinstalling
warning: nvidia-utils-295.59-1 is up to date -- reinstalling
warning: downgrading package linux (3.4.4-2 => 3.3.7-1)
resolving dependencies...
looking for inter-conflicts...Targets (3): linux-3.4.4-2 nvidia-295.59-1 nvidia-utils-295.59-1
Total Installed Size: 117.05 MiB
Net Upgrade Size: 0.00 MiBProceed with installation? [Y/n] Y
(1/3) checking package integrity [########################################] 100%
(1/3) loading package files [########################################] 100%
(3/3) checking for file conflicts [########################################] 100%
(3/3) checking available disk space [########################################] 100%
(1/3) upgrading linux [########################################] 100%
>>> Updating module dependencies. Please wait ...
>>> Generating initial ramdisk, using mkinitcpio. Please wait...
==> Building image from preset: 'default'
-> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 3.4.4-2-ARCH
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [pata]
-> Running build hook: [scsi]
-> Running build hook: [sata]
-> Running build hook: [filesystems]
-> Running build hook: [usbinput]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip initcpio image: /boot/initramfs-linux.img
==> Image generation successful
==> Building image from preset: 'fallback'
-> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: 3.4.4-2-ARCH
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [pata]
-> Running build hook: [scsi]
-> Running build hook: [sata]
-> Running build hook: [filesystems]
-> Running build hook: [usbinput]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip initcpio image: /boot/initramfs-linux-fallback.img
==> Image generation successful
(2/3) upgrading nvidia-utils [########################################] 100%
(3/3) upgrading nvidia [########################################] 100%
[christer@Arch Archlinux+++]$
I also run:
grub-mkconfig -o /boot/grub/grub.cfg
To regenerate grub2 (I dont know it it is nessesary).
But after reboot, still 3.4 kernel.
Any idea what I am missing?
Best regards,
Christer
After updating the system almost daily it would now be a nightmare to downgrade, so I dont think it is an option for me now.
Remembering that to downgrade your kernel, you don't necessarily have to downgrade your entire system. Most of the packages on your system don't care what kernel version you're running as long as it's not, you know, 2.4...
You can always pull a working 3.3 era kernel out of the arch rollback machine if you've lost it in your cache.
So far the only packages I've needed to downgrade to fix this problem are linux, linux-headers, nvidia, and nvidia-utils. [and of course, their lib32 equivalents]
I use the rt2870 from AUR.
It have now been two kernel releases since I first experienced the problems.
After updating the system almost daily it would now be a nightmare to downgrade, so I dont think it is an option for me now.
hope a solution will come soon. I believe so
]]>Kiirani wrote:The band-aid solution for now has been to use my package cache to downgrade packages linux, linux-headers, nvidia, and nvidia-utils to the previously installed versions - kernel 3.3.7-1-ARCH works fine. Nothing on my system other than nvidia had problems with kernel < 3.4, and the latest driver version is not currently a requirement.
Network traffic seems to be the problem on my system as well, it works fine with ethernet.
How did you get around the nvidia/kernel-3.4 catch 22? Force-downgrade?
-peter
I reinstalled nvidia and nvidia-utils 295.53-1 from my package cache. (This just happens to be the next-latest version sitting in there). Had to grab lib32-nvidia-utils in a matching version from the arch rollback machine.
I didn't really find a catch 22 about it, possibly because I threw the kernel and nvidia into the one downgrade command.
]]>The band-aid solution for now has been to use my package cache to downgrade packages linux, linux-headers, nvidia, and nvidia-utils to the previously installed versions - kernel 3.3.7-1-ARCH works fine. Nothing on my system other than nvidia had problems with kernel < 3.4, and the latest driver version is not currently a requirement.
Network traffic seems to be the problem on my system as well, it works fine with ethernet.
How did you get around the nvidia/kernel-3.4 catch 22? Force-downgrade?
-peter
]]>crystaly wrote:Are you using a ralink card (ethernet or wlan) ?
Yes, I am, an RT3060 Wireless card. I am using a hand-compiled driver (DPO_RT3562_3592_3062_LinuxSTA_V2.4.1.1).
Poking head in for a me-too on this one.
Just started getting kernel panics after updating to 3.4.4-2-ARCH. They seemed to be caused by network traffic, hence why I'm here.
I'm running an Asus USB-N13 wifi adapter. It identifies itself as an RT3072
Regarding the suggested option of moving to the rt2800usb driver a few posts back - this driver does not work as advertised for this card, which is why I've been compiling my own from the official sources.
The band-aid solution for now has been to use my package cache to downgrade packages linux, linux-headers, nvidia, and nvidia-utils to the previously installed versions - kernel 3.3.7-1-ARCH works fine. Nothing on my system other than nvidia had problems with kernel < 3.4, and the latest driver version is not currently a requirement.
]]>Are you using a ralink card (ethernet or wlan) ?
Yes, I am, an RT3060 Wireless card. I am using a hand-compiled driver (DPO_RT3562_3592_3062_LinuxSTA_V2.4.1.1).
The build-in ethernet is Realtek. Hm, maybe I should disconnect the wifi and see what happens...
-peter
addition: yep, that made a difference, no panic with ethernet, panic with wifi...
]]>Are you using a ralink card (ethernet or wlan) ?
]]>