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. What kind of PC are you testing your CardBus adapter? Is that a 32bit or 16bit? Cheers, -FG > > > Larry > ------- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
