Bug 79433
| Summary: | prism2 (2.5) wireless card - hardware initialization probelm? | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Pam Huntley <pam_huntley> |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | tcallawa, wdc |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-12-16 05:26:43 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Pam Huntley
2002-12-11 17:29:11 UTC
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. |