You are not logged in.
Thanks - I was using the LTS kernel to work around this on my i686 netbook (mostly on the grounds that trying to compile on it would be hilariously slow and the LTS one works with that hardware decently). Does anyone know about the progress on getting this fixed in the mainline kernel? My googling indicates it might be fixed in 3.11...
This has been sent upstream:
http://mid.gmane.org/1377020634-27064-1 … penwrt.org
Though it has not yet been applied I think. At least 3.10.10 does not have it.
ArchLinux - make it simple & lightweight
Offline
One question: do you guys get a kernel panic everytime you use the driver or is it an intermitent problem? I ask this because I had a few crashes but right now, for example, I'm using the driver and the kernel seems to be OK with it. Using core/linux 3.10.9-1.
Offline
The bug this addresses (for me) comes up as soon as you establish a connection and then an application uses it. For instance, Wicd will establish the connection fine, but as soon as Skype loads as well and tries to connect, instant kernel panic every time.
Avatar by Ditey: https://twitter.com/phrobitey
Offline
It seems to be an issue with the way your router is set up ... If I switch my router from "up to 144Mbps" to "up to 54Mbps" (most likely just disabling 802.11n). The kernel panic issue goes away. So far had an uptime of over 4 days on 3.10.9-1-ARCH.
Offline
Thanks, again.. ;]
Offline
I got broadcom-wl working fine on my BCM43224 under 3.10.10-1, but thanks eworm for your effort anyway.
Last edited by paranoiac (2013-09-02 07:31:42)
Offline
yes, I have this problem just when I tried to connect a 802.11n AP.
802.11 b/g is ok
Offline
I got broadcom-wl working fine on my BCM43224 under 3.10.10-1, but thanks eworm for your effort anyway.
Working also good with
0d:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
It's a shame though with the new kernel and open-source drivers this bug is not yet fixed.
Offline
For anybody interested... The fix has been merged in Linus' tree and will be in 3.11:
ArchLinux - make it simple & lightweight
Offline
About time.
Again, thank you eworm.
Offline
About time.
If you had looked at the link that eworm provided there, it was actually committed some 12 days ago… and the bug was reported by an Arch dev. So it wasn't as though there was nothing being done about it.
Offline
Woofy, I think sardina is just happy about the fact, that it happened, no matter how. And so am I. It's nice to see, how effective this community can be.
Offline
sardina wrote:About time.
If you had looked at the link that eworm provided there, it was actually committed some 12 days ago… and the bug was reported by an Arch dev. So it wasn't as though there was nothing being done about it.
It was related to the post previous to mine.
I meant that after almost 2 weeks (yes, I did look at things) it's good news they merged the fix in master tree.
EDIT:
Basically like Awebb said.
Last edited by sardina (2013-09-03 13:45:17)
Offline
For anybody interested... The fix has been merged in Linus' tree and will be in 3.11:
Good to know. ;]
Offline
It's worth noting: I get the kernel panic when connecting to encrypted wifi, but when I connect to an unsecured network it works fine.
Offline
Everything fixed in 3.11, as eworm pointed out!
Offline
At least 3.10.10 does not have it.
After a couple of times I got no kernel panics with 3.10.10-1, this evening I got another couple of panics... so I had to downgrade again to 3.9.9 (from my cache) and starting again to wait for a newer kernel because 3.10.10 seems not to definetely fix this issue.
Some has said 3.11 will fix it... so I'm waiting for it
Offline
You can see for yourself, as 3.11 is in [testing].
Offline
I wouldn't use a package from Testing... ;-)
Offline
I wouldn't use a package from Testing... ;-)
With how easy it is to downgrade back to the older kernel, I don't really see why you wouldn't give this a try. Particularly if you suspect it would fix something like regular kernel panics.
Using the kernel from [testing] does not mean that you would have to enable to whole repo. Just go download the single package from your favorite mirror and have at it! Though, if you use any 3rd party modules, you shoudl have to also download those as well (for example, virtualbox modules, r8168, etc.). But even then, it is still just a very small number of packages.
Offline
Using the kernel from [testing] does not mean that you would have to enable to whole repo. Just go download the single package from your favorite mirror and have at it!
Yes, you can do that, but always keep in mind that it's unsupported.
Offline
While it may be technically "unsupported" the kernel itself does not link against a whole bunch of other libs and whatnot. So typically changing out just the kernel (and any necessary 3rd part module packages) is a pretty legit thing to do.
The problem with partial upgrades is that the dependencies are not version in favor of simplicity and avoiding unnecessary rebuilds. The assumption is that users are expected to keep their machine up to date, so this shouldn't be an issue if users actually do. But typically the issue of partial upgrades arises from having package 'A' that depends on ≤1.0 of package 'B'. But this versioned dependency is not listed, as it is expected that when I user installs the new version of 'A' that the new 'B' will be updated with it.
Besides, I think that venturing into unsupported territory (potentially even just momentarily) to see if kernel panics stop is certainly worth it. Especially when moving back to the [core] packages is just an -Syuu away.
Offline
While it may be technically "unsupported" the kernel itself does not link against a whole bunch of other libs and whatnot. So typically changing out just the kernel (and any necessary 3rd part module packages) is a pretty legit thing to do.
The problem with partial upgrades is that the dependencies are not version in favor of simplicity and avoiding unnecessary rebuilds. The assumption is that users are expected to keep their machine up to date, so this shouldn't be an issue if users actually do. But typically the issue of partial upgrades arises from having package 'A' that depends on ≤1.0 of package 'B'. But this versioned dependency is not listed, as it is expected that when I user installs the new version of 'A' that the new 'B' will be updated with it.
Thank you for that clarification! Nice to have the technical reasons for that policy laid out so simply.
Besides, I think that venturing into unsupported territory (potentially even just momentarily) to see if kernel panics stop is certainly worth it. Especially when moving back to the [core] packages is just an -Syuu away.
I think so too. I mean, most of the reason why I use Linux is because I like to break things and try to repair them after
That said, the whole "keep in mind" thing is so that whoever tries that is aware that it is potentialy dangerous and they shouldn't be surprised if stuff break and people tell them afterwards that they "shouldn't have done that".
So yeah, if you're no ready for that kind of fun, don't go that way
Offline
So yeah, if you're no ready for that kind of fun, don't go that way
OTOH, if you are not ready for that kind of fun, you probably shouldn't be using Arch Linux anyway…
I too like to tinker 'til things bork. Or I guess ideally I would like to tinker until things get awesome, but things often break, so it is a good thing I don't mind fixing and learning.
Offline
Linux 3.10.11 will have the needed patch too:
http://www.spinics.net/lists/kernel/msg1597722.html
Offline