RE: PROBLEM: brcm80211 hangs on 2.6.36-0.34.rc6.git3.fc15.x86_64

Brett Rudley
2010-10-08T17:45:31Z

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 2034 bytes --]

Thanks for the input.

The 4313 (Device ID 4327) is pretty solid on the 32 bit staging-next kernel (loads, runs
for days, no issues, etc).

On the other hand, I haven't been using anything other than that kernel recently so its
very, very likely there are problems with other kernels, especially 64 bit which I haven't even
attempted yet (but will of course). Please do try out the 32 bit staging-next kernel and let me know how it goes.

Yeah, turning on msglevel produces more (and possibly *much* more) output.

Let me know what you find,
Thanks
brett

> -----Original Message-----
> From: Jon Masters [mailto:jonathan@jonmasters.org]
> Sent: Friday, October 08, 2010 4:44 AM
> To: linux-wireless@vger.kernel.org
> Cc: Brett Rudley; Henry Ptasinski; Nohee Ko; Jon Masters; LKML
> Subject: Re: PROBLEM: brcm80211 hangs on 2.6.36-0.34.rc6.git3.fc15.x86_64
>
> On Fri, 2010-10-08 at 02:58 -0400, Jon Masters wrote:
>
> > I tried building the new brcm80211 driver from staging-next on Fedora
> > rawhide kernel 2.6.36-0.34.rc6.git3.fc15.x86_64. Now, of course, it's
> > not the staging-next kernel (I'll try that now this doesn't work) but
> > perhaps this report will still be of use to the Broadcom/other wireless
> folks.
>
> I pulled the latest staging-next onto Linus' latest git tree and still
> experience problems with the driver. It seems that the first attempt to
> actually transmit results in the system locking hard. Once again, I am
> attaching the output from running a netconsole (due to the box I'm on,
> it's an attachment this time, sorry about that - don't trust evolution)
> where the trace is basically the same as the original trace I posted.
>
> NOTE: in both cases, the driver is loaded with "msglevel=2 phymsglevel=2"
> which (although not documented) suggests to enable tracing, and does
> certainly yield more debugging output.
>
> Jon.

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éÝ¶\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dÊ‡Ú™ë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥