brian.xu wrote:
>
>
>> On our SPARC platforms, it is dealt with entirely in hardware and low
>> level platform firmware. Most miniPCI adapters have a special pin on
>> them that can be tied to an RF button, and they usually do something
>> sensible with it. So with miniPCI it is *almost* automatic. The
>> problem is that on x86 hardware there is often ACPI getting in the way.
>>
>>
> understood.
>
>> Does the new code properly ensure that overlapping accesses to buffer
>> paths 0 and 1 are not used on miniPCI hardware? There is a known errata
>> in miniPCI where overlapping accesses to channels 0 and 1 can cause a
>> hardware hang. The only software workaround is to guarantee a minimum
>> delay between accesses to paths, or restrict accesses to only a single
>> path. (I chose the latter approach.)
>>
>>
>>
> I have not noticed it yet.I did not suffer with hardware hang due to
> the errata.
> Just as the pcwl driver, channel 0 and 1 is separately used as cmd and
> data path.
I used a similar but different strategy in an earlier version of my own
driver. I used channel 0 as cmd data and rx data, but channel 1 as tx
data. But it still led to occasional hangs. Usually you need to drive
the interface pretty hard to hit it. Run two ttcp streams and you might
see it.
I highly recommend you consider either adding a delay (forgot how long
it needs to be -- I should probably check the errata), or just switching
to a single BAP path. The problem isn't just one of if you use one
path or the other simultaneously -- its if you use one path or the other
within a certain small window of time. Its an ugly ugly errata.
>
>> What about firmware updates? There are problems with PRISM devices that
>> are fixed with firmware updates, and some newer PRISM devices (PRISM 3)
>> _require_ a RAM firmware upload, because they lack sufficient flash
>> memory to hold the run-time firmware image ("secondary firmware" in
>> Intersil parlance) on device.
>>
>>
>>
> that driver doesn't support firmware update.
That's most unfortunate. There are some important fixes in some of the
recent firmware revs.
>
>> I would like to get a copy of the code if possible.
> surely. I will post it on opensolaris soon.
Cool.
>
>> I may be able to
>> review it for known problems and send any appropriate fixes.
>>
>>
> thanks.
No problem.
>
>>
>>
>> Right. Thou shalt not block/sleep in STREAMs routines (including all
>>
>> GLD entry points) other than open and close. (Sleep in DDI
>> attach/detach is OK, of course.)
>>
>>
> Yes.
>
>> This isn't the only driver that makes this mistake, and it will rarely
>> cause a problem, but it should be fixed.
>>
>>
>>
> I develop&debug realtek wifi driver recently and encounter such a
> deadlock.
> since 'scan' is not invoked frequently, I use a spin
> wait--drv_usecwait().
That's a really, really bad idea. You're talking about spinning for a
whole second. _Everything_ on the machine stops while this is
happening. Even interrupts will be blocked. I strongly urge against
this approach.
>
>> Because of all of these complications, I found it much easier in my code
>> to split the scanning logic into two ioctls. The first ioctl asked the
>> hardware to initiate a scan. The 2nd ioctl reads the results.
>>
>>
>>
> wificonfig split the scan logic into two ioctls as you said. so the
> driver
> can also fulfil it.
Well that will work too.
-- Garrett
>
> Thanks,
> Brian
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
