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 > > 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