On Saturday 31 January 2009 20:15:22 Francesco Gringoli wrote: > On Jan 31, 2009, at 7:54 AM, Larry Finger wrote: > > > Francesco, > > > > I changed the dma.c code to WARN_ON rather than BUG_ON and also dump > > the cookie for the erring case. Of course, the system no longer > > crashes, nor even stops on the first error. I have no idea how many > > errors occurred before I got it stopped, but the cookies for the first > > few offending frames were 0x2030, 0x2032, 0x2048, 0x204c, 0x204e, > > 0x2050, and 0x2052. > > > > When I got it stopped, I dumped /sys/kernel/debug/b43/phy0/txstat and > > obtained: > > > > [cut] > Larry, > > many thanks for your help in debugging. However I can't reproduce that > error. I tried all this afternoon with a 4306rev3 on a CardBus board > but all efforts to freeze the PC were useless. I checked again the > difference between r5.0 and r5.1 but it is only 10 lines... so easy to > debug that I'm pretty sure that error is not due to changes into > header offsets. > > > Is there any way for me to me to freeze the interface when the first > > error occurs without inducing a kernel panic? > I don't understand completely your question: if you need to stop the > firmware without having its memory corrupted we can add a semaphore > just after the WARN_ON into shm so that next loop after > state_machine_start we enter an infinite loop. However this would > happen after hundreds cycles. Tell me if we can helping adding debug > blocks into the firmware.
You can stop the PSM immediately, if you need to, with the MAC_CONTROL. See b43-fwdump, it uses it to get a consistent dump. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
