From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitri Seletski Date: Mon, 06 Apr 2009 22:17:32 +0100 Subject: [ath9k-devel] ath9k vs nvidia(proprietary) In-Reply-To: <1239051432.15621.83.camel@mj> References: <49D873BE.8050908@gmail.com> <1238989468.32736.23.camel@mj> <49DA62AC.7040102@gmail.com> <1239051432.15621.83.camel@mj> Message-ID: <49DA716C.6040904@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Pavel Roskin wrote: > On Mon, 2009-04-06 at 21:14 +0100, Dmitri Seletski wrote: > >> Pavel Roskin wrote: >> >>> On Sun, 2009-04-05 at 10:02 +0100, Dmitri Seletski wrote: >>> >>> >>>> Hello Guys. >>>> >>>> I can pretty much say, unloading nvidia driver and reloading ath9k >>>> module fixes connection. >>>> However, in my case it's pretty bad for me... I am heavy gamer, and SLI >>>> nvidia cards dusting doing nothing ,well, it's pretty bad. >>>> I suspect i may have sort of a trouble with IRQ sharing. >>>> >>>> >>> >>> >>> >> I was specifically advised to unload nvidia driver previously by one of >> developers. I have provided quite some information about my machine, >> sorry for not keeping track of those emails, i'll try to be smarter next >> time and keep history of previous emails. >> > > It's possible that you were asked to do that simply because the nvidia > driver is a "black box", which cannot be audited for code quality. > Developers are happier to help is such black boxes are kept away from > the system under testing. It doesn't necessarily imply there is a > conflict between the drivers. It's just an attempt to exclude > unpredictable inputs while testing. > Perfectly understandable, now i am in my X from uner VESA compiled in... > >>>> Is it possible for me to give some load parameters >>>> to ath9k module to force it to use another IRQ?(like some other drivers >>>> do?) >>>> >>>> >>> That's not ath9k specific in any way. >>> >>> >>> >> Arm, what do you mean not specific? That phrase makes no sense to me. >> From what i know not every device driver has ability of changing IRQ as >> required. >> > > Generally, it should not be needed. Also, IRQ assignment is not done in > individual drivers of PCI devices. If you need it badly, perhaps the > PCI people can help (linux-pci at vger.kernel.org). But most likely you > will be told that you are doing something wrong. > Not that I am doing something wrong. i am NOT doing anything. > >> You can think of my previous phrase as possible feature >> request, or a question of "how to?" type. I know that borh SLI nvidia >> cards are sharing IRQ 16 as well as atheros based dlink wireless card. >> (if it's not difficult, please look into my previous emails, they will >> have dmesg and lspci -vv details, otherwise just ask me for more >> details, i shall provide them) >> > > It should not be a problem. You can try some workarounds, such as the > "irqpoll" option on the kernel command line. > > One fun project would be to enable MSI (message signaled interrupts) in > ath9k. It's not guaranteed to help in your situation, but it would be a > welcome contribution to the code. It should not be not very hard. > Well, how can i help? I am not coder... I dont speak C ;) > >>>> Obviously, there is not much point of asking Nvidia to do it, since >>>> those behemoth's won't do anything for sure, since their current driver >>>> (i dont use it for that matter)release is pretty banged up... >>>> >>>> >>> If you do most of the work finding how to work around the problem, and >>> it turns out that something could be improved in free software, then >>> maybe your patch will be applied. >>> >>> If you expect others to question you about the symptoms, then suggest >>> patches and push them to the kernel, that's not going to happen. >>> >>> >> Symptoms are simple with nvidia module and ath9k loaded at the same time >> connection degrades over short period of time and after several minutes >> disappears all together. I suspect it could be IRQ sharing or other I/O >> or similar hardware conflict, since both of them work pretty well while >> other devices driver is not loaded. no unusual messages in dmesg. >> Machine may hang and even if in terminal(not in X), machine hangs >> completely without providing a bit of information, not even oops message. >> > > ath9k used to hand for me with SLUB debugging enabled. I debugged it > and submitted a patch recently, but it didn't make it to > wireless-testing yet (it looks like wireless-testing maintainers are > away for more than a week). > > If you are lucky, you could find another problem in ath9k. Then your > contribution will be welcome. But you may find no obvious problem in > ath9k. > > I could dust off an nvidia card and try ath9k with it, but I have other > priorities, such as WDS testing. > > >>>> Another question, my Access Point and PCI wifi card are from same >>>> manufacturer. AP is set to B,G,N auto mode, but my card only connects to >>>> it using G mode, which is not why i bought it in the first place. Why is >>>> this happening? i am pretty much only user to network myself 99% of >>>> time. i tried to force it to use N mode, it could detect it, but it >>>> couldn't connect. >>>> >>>> >>> I suggest that you actually show what commands you run and what they >>> return, not just your interpretation. >>> >>> In case you are hitting the stuck scan bug, try setting the channel with >>> iwconfig instead of loading and unloading modules. >>> >>> >>> >> Commands are simple as well. >> ip link set wlan0 up >> iwconfig wlan0 essid dlink >> they don't give any errors and don't show any unusual messages in dmesg >> >> thats pretty much it. (no wireless security used at all) >> > > I mean, it you lose connection, try "iwconfig wlan0 channel 6" (or > whatever channel the AP is on. It will unblock whatever is stuck in the > kernel. That's another thing I'd like to have a look at before I even > touch that nvidia card. > > >> N.B. >> What i really don't want is any kind of aggression towards to me. >> > > Of course. If you wanted aggression towards you, you would have written > to LKML :-) > > >> Coding something for a community, even advanced one requires certain >> amount of tolerance, as ANY normal communication. >> I am not perfect tester(i just attempt to become better one), i >> understand that, but i am not coming after difficult day, working with >> difficult people to submit difficult issues(which other people may >> prefer to ignore all together or for those reasons abandon Linux and go >> to MS products, i have seeing enough of those). I am not going to become >> more enthusiastic by being referred to "RTFM noob" like documents, who >> nearly imply my stupidity. >> So far I was very happy in this list, and even my lack of technical >> knowledge did not spoil my attitude towards this list. I want it to stay >> that way. Ignoring problems of people who lack technical knowledge on >> matter is path to nowhere. I seriously, don't want to start flame wars, >> i am not naive and I don't ask for apologies. I just ask one thing, >> please be tolerant, everyone can have a shi*** day, that includes you >> and me! >> > > It's totally unnecessary to vent your frustration here, especially to > those who never called you a noob or something. > Like I said, i am not going to start flame wars... An no, you did not call me noob. Its not my point, i am here to solve my problems, and in some way to help other people to solve theirs. If I suck at it - tell me what to do to improve my skills of "debugging" drivers. Links to documentation that call me stupid are not doing any help. Anyway, I am loading nvidia drivers and see how all that works... will try that trick with with channel number if connection fades away. What i also noticed, "iwlist wlan0 scan"(interface is up) doesn't bring any results there either... Anyway, let me try it and i shall report back. Dmitri