Larry, et. al.,
I was that close! After the various steps and procedures I had the bcm
driver kit "installed" and the knetwork manager said I was online. No
applications were connecting so I rebooted, and had to re-inRe:
Bcm43xx-dev Digest, Vol 16, Issue 28 install the OS. Back on the
computer now, driver kit installed according to the gui installers, but
not making the trip past the "IP configuration" stage (the "57%" on the
progress bar graph). Any sage advice would be welcome, and saved out of
reach in case of another crash!
r.e.
[EMAIL PROTECTED] wrote:
> Send Bcm43xx-dev mailing list submissions to
> bcm43xx-dev@lists.berlios.de
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
> or, via email, send a message with subject or body 'help' to
> [EMAIL PROTECTED]
>
> You can reach the person managing the list at
> [EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bcm43xx-dev digest..."
>
>
> Today's Topics:
>
>1. [PATCH] b43: Fix rfkill callback deadlock (David Ellingsworth)
>2. Re: [PATCH] b43: Fix rfkill callback deadlock (Michael Buesch)
>
>
> --
>
> Message: 1
> Date: Mon, 29 Oct 2007 21:58:00 -0400
> From: David Ellingsworth <[EMAIL PROTECTED]>
> Subject: [PATCH] b43: Fix rfkill callback deadlock
> To: bcm43xx-dev
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="windows-1252"
>
>
> Forgot to send to list
>
>
>> From: [EMAIL PROTECTED]
>> To: [EMAIL PROTECTED]
>> Subject: RE: [PATCH] b43: Fix rfkill callback deadlock
>> Date: Mon, 29 Oct 2007 21:56:51 -0400
>>
>>
>>
>>> From: [EMAIL PROTECTED]
>>> To: bcm43xx-dev@lists.berlios.de; [EMAIL PROTECTED]
>>> Subject: Re: [PATCH] b43: Fix rfkill callback deadlock
>>> Date: Mon, 29 Oct 2007 01:16:05 +0100
>>>
>>> On Monday 29 October 2007 01:06:51 David Ellingsworth wrote:
>>>
> - mutex_lock(&wl->mutex);
> + /* When RFKILL is registered, it will call back into this callback.
> + * wl->mutex will already be locked when this happens.
> + * So first trylock. On contention check if we are in initialization.
> + * Silently return if that happens to avoid a deadlock. */
> + if (mutex_trylock(&wl->mutex) == 0) {
> + if (b43_status(dev) < B43_STAT_INITIALIZED)
> + return 0;
> + mutex_lock(&wl->mutex);
> + }
> if (b43_status(dev) < B43_STAT_INITIALIZED)
> goto out_unlock;
>
Why not replace everything above up to and including the '-
mutex_lock(&wl->mutex); with:
if(b43_status(dev) < B43_STAT_INITIALIZED)
return 0;
mutex_lock(&wl->mutex);
>>> because the status should be queried under lock, of course.
>>>
>> If that is the case, then a proper fix would be to use two locks to protect
>> access to the status. One for allowing read access when no one is writing,
>> and another for allowing exclusive write access. In such a configuration you
>> could allow multiple readers while having only one writer. The above fix is
>> not proper since the lock obtained by another section of code could be
>> released before or during the status check.
>>
>> Regards,
>>
>> David Ellingsworth
>> _
>> Peek-a-boo FREE Tricks & Treats for You!
>> http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us
>>
>
> _
> Windows Live Hotmail and Microsoft Office Outlook ? together at last. ?Get it
> now.
> http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> https://lists.berlios.de/pipermail/bcm43xx-dev/attachments/20071029/f843da81/attachment-0001.html
>
>
> --
>
> Message: 2
> Date: Tue, 30 Oct 2007 11:06:53 +0100
> From: Michael Buesch <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] b43: Fix rfkill callback deadlock
> To: [EMAIL PROTECTED]
> Cc: bcm43xx-dev@lists.berlios.de
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tuesday 30 October 2007 02:56:51 David Ellingsworth wrote:
>
>> If that is the case, then a proper fix would be to use two locks to protect
>> access to the status. One for allowing read access when no one is writing,
>> and another for allowing exclusive write access. In such a configuration you
>> could allow multiple readers while having only one writer. The above fix is
>> not proper since the lock obtained by another section of code could be
>> released before or during the status check.
>>
>
> We don't care for that case, as the status is rechecked under lock later.
> This really is not a problem.
> We only care for the case where status!=INITIALIZED. Because
