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)
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
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
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):
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
4. the reverse order works fine (ie windows first)
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:
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
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
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.
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
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?
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.