Red Hat Bugzilla – Bug 79433
prism2 (2.5) wireless card - hardware initialization probelm?
Last modified: 2007-04-18 12:48:59 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 Description of problem: I work at IBM, and I got a call from Bill Cattey at MIT, describing this. He has many machines that are dual boot, and he is seeing this problem: if Linux uses the wireless card _first_, then it is broken when you go back to windows. Once you reset the card under windows, it works again. Works fine the other way around. I _know_ you all don't care about windows, but after looking at it some it appears that it _might_ be a problem with the Linux driver not initializing the hardware correctly. Part of the reason I think this is that the driver used for the prism2 card is the orinoco_pci, which isn't really the same chipset, and it has issues besides just this. I can help with specifications.... Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. dual boot machine, boot up to linux first 2. send bits over wireless card w/linux 3. reboot to windows, card is BROKEN. must disable then re-enable to get it to work. 4. the reverse order works fine (ie windows first) Additional info: If you all need hardware specifications, I would be happy to leverage IBM 's contacts to help you get the specs. Some of them are available on the web here: http://www.intersil.com/design/prism/ser-p25-11mbps.asp If that is not enough, please let me know, I've already talked to IBM's interface into Intersil, it should be possible to get you whatever you need. Also, Bill has some of the offending machines in his possession, he said that he would be happy to dump the state of any registers or whatever debugging was required, he just needs someone to tell him what utilities to use.... Please contact me for his email.
Means your windows card init is broken not the Linux one
It is a sad day when the Linux development community is willing to let lesser operating systems like Windows win when a little bit of care and thought can resolve real problems. I thought, "It's the other operating system's fault -- bug closed" was the sort of behavior we'd relegated to Microsoft. Please give this bug some more thought! Perhaps I'm being old fashioned or silly, but, "Boot windows, and re-initialize the card by hand after Linux is done with it" does NOT seem like an appropriate work around for a pair of drivers that don't seem to want to get along. PLEASE REOPEN THIS BUG The whole reason why I make it my business to make Linux attractive to end users and big-whigs with signature authority over big dollars is that for the most part, the Linux community will DIG IN, FIND, AND FIX THE PROBLEM. Mr. Cox, you disappoint me in the extreme. Your quick closeout to this message comes before I have been able to report yet more problems I am having with the Orinoco driver and my card which also have a simple work-around: If you're on an IBM system with working suspend/resume, if you begin to get tens of thousands of kernel: eth0: Error -110 writing Tx descriptor to BAP errors, just close the laptop and open it and the suspend/resume will clean up tghe mess. If it is a Dell you have, give up. It is the Dell BIOS's fault. Is there SOMEONE on this list who will work with me on a more constructive approach to improving the Orinoco driver?
There is *NOTHING* we can do about broken windows drivers. When the card is initialized the relevant OS has to initialize it properly from scratch. Linux cannot change how Windows initialises the hardware to fix their driver, sorry. If its an IBM then the IBM laptop people need to fix their windows driver to initialize the board more carefully I suspect. On the Linux side I can only work on the points Linux has control of - Booting Linux after windows has run, booting Linux as the first OS, and booting Linux after Linux has run. Suspend/Resume problems are a different matter. What you are describing sounds like the firmware on the card crashed (either due to bugs or because Linux told it do something it didnt like http://hostap.epitest.fi/or both), but thats for a different bug. Longer term we are looking at the HostAP drivers which replace the standard kernel prism driver, seem to be more reliable and can also work as an access point. http://hostap.epitest.fi/ Wireless stuff is very hard to debug. Most firmware/cards work very well, some work fine with modern firmware and not older (eg the WL100), others are still problematic.
I've not been inside the driver, so until I do read the code, I'll have to defer to you on this. However, it seems MIGHTY STRANGE, that hundreds of systems ship with no problems with the Wireless cards as they ship out of IBM under XP, and the ONLY time the problem manifests is when XP runs AFTER Linux has been installed and tries to use the card. From the last extremely subtle Ethernet driver bugs I've worked through (notably a strange interaction with Etherboot and the 3c59x driver and certain chip revs) that REALLY smells like a, "Orinoco driver on hardware that emulates the Orinoco card making subtle assumption that comes back to bite other driver in other context. In fact, your response leads me to a focused question: Doesn't this sound like a case where if Windows DID initialize the card from scractch all would be well, and maybe the fact that Linux is getting its hands on the initialization first is causing the problem? My testing is somewhat anectdotal, and "If Linux initializes the hardware first" may well be the underlying issue. Given that this problem apparently disappears forever as soon as I tell Windows to disable then re-enable this card, is there any test you can suggest I run to create a "Fresh from the Factory" state in the card, and then retry initializations first under Linux then "first" under Windows? -wdc
Alan, Thanks for your comments on the bug. I talked to Jeremy Katz about it as well, he said it was less of a case of "improper initialization" and more a case of "incompatible initialization", in which case the Windows driver should be fixed. I'll talk to Intersil to see if they will fix it. (I work at IBM). I'm also planning on asking about how to set up an NDA between Red Hat and Intersil that will still allow for open source code. I'm still seeing the connection going down about every 8 hours or so (which of course is a separate bug), one of the other developers at Red Hat said the specs would help with that.