linux-kernel - Re: iwl4965: "MAC is in deep sleep!" freezes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 8 Sep 2011 18:19:56 +0200
From:	Stanislaw Gruszka <sgruszka@...hat.com>
To:	Christoph Anton Mitterer <calestyo@...entia.net>
Cc:	Jonathan Nieder <jrnieder@...il.com>,
	linux-wireless@...r.kernel.org,
	"John W. Linville" <linville@...driver.com>,
	Greg Dietsche <Gregory.Dietsche@....edu>,
	linux-kernel@...r.kernel.org
Subject: Re: iwl4965: "MAC is in deep sleep!" freezes

On Thu, Sep 08, 2011 at 10:49:13AM +0200, Stanislaw Gruszka wrote:
> On Mon, Sep 05, 2011 at 09:42:01AM +0000, Christoph Anton Mitterer wrote:
> > On Mon, 5 Sep 2011 11:19:18 +0200, Stanislaw Gruszka <sgruszka@...hat.com>
> > wrote:
> > > this look like firmware hang. This happen just after module load, that's
> > > good news, because it allow to log relative small amount debug messages
> > > to see what possibly driver do wrong to crash firmware.
> > Note, that the effects of - usually but not always - frozen system while
> > the errors are printed (sometimes keyboard input seems still be possible
> > during that) ... happen over and over again... say about every  10 minutes
> > or so.
> > Not just the first time the modules is loaded.
> > Is the firmware loaded over and over again?
> I think is not, but even if is, kernel should not crash. Can you grab
> crash logs using photo camera, serial cable or netconsole, to allow to 
> see where exactly crash happen and fix it.
> 
> > > Please configure syslog to log kernel debug messages.
> > Will mail it later.
> 
> Firmware hang seems to happen when REPLY_LEDS_CMD command is send.
> No idea if attached patch could help or not, but is worth to try it.
> It prevent to send LED command asynchronously, when possibly some
> other commands are pending in firmware.
> 
> If it does not help, please provide the same way captured debug
> messages from 2.6.38 kernel, where drivers works. I'll compare
> it with broken driver logs to figure out what broken driver
> do differently.

Sorry, forgot attch the patch, do it now.

Stanislaw

View attachment "led_work.patch" of type "text/plain" (4320 bytes)