[ath9k-devel] ath9k vs nvidia(proprietary)

[Dmitri Seletski <drjoms@gmail.com>]

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