On Tuesday 18 December 2007 17:14:54 Ehud Gavron wrote:
> I've trimmed some of this.
>
> Michael Buesch wrote:
> >>> I have no idea. But I don't understand why waiting a random time up to
> >>> 1000ms fails
> >>> and a random time up to 1000ms + 1ms succeeds.
> >>>
> The patch I submitted had a newbie-error. Right before making the patch
> I removed the debug messages. As it turns out it's not the msleep that
> makes the difference. It's having TWO debug messages AND the msleep.
>
>
> Yes, I know that sounds stupid. Here are the kernels I built to test
> this stupid theory:
> /boot/vmlinuz-2.6.24-rc5-1dm
> /boot/vmlinuz-2.6.24-rc5-m1.dm
> /boot/vmlinuz-2.6.24-rc5-dm.dm
> /boot/vmlinuz-2.6.24-rc5-dm.m1
> /boot/vmlinuz-2.6.24-rc5-duh
>
>
> DM=display message
> M1=msleep(1)
> DUH=go back to square one, display message; msleep(1) ; display message.
>
>
> This DOES WORK and DOES TURN ON THE LED. However...
> Here's the really funny thing. Here are the messages:
>
> b43-phy0: Radio hardware status changed to ENABLED
> b43-phy0: EHUD: LED coming on
>
> And here's the code:
>
> if (unlikely(report_change)) {
> b43info(wl,"EHUD: sleeping\n");
> msleep(1);
> b43info(wl,"EHUD: LED coming on\n);
> input_report_key(poll_dev->input, KEY_WLAN, 1);
> input_report_key(poll_dev->input, KEY_WLAN, 0);
> }
>
> So my question (other than why do I need two messages and one msleep to
> get my LED lit) is... what happened to the "EHUD: sleeping" debug
> message? It never showed up on the console. I did this several times.
> The full dmesg is attached.
>
> Ehud
>
>
This smells like a compiler bug.
Can you try an older compiler version?
(Most distros ship several versions)
--
Greetings Michael.
_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
