Saladino wrote: >Hi, it is the usb handler i supose(when i unplug the usb mouse it >works correctly) i can paste the whole backtrace if its needed. >Thanks for your time >Saladino > >2005/10/31, Benjamin Herrenschmidt <[EMAIL PROTECTED]>: > > >>>. >>>radeonfb (0000:00:10.0): suspending to state: 2... >>>radeonfb (0000:00:10.0): resuming from state: 2... >>>PCI: Enabling device 0000:00:10.0 (0000 -> 0003) >>>PCI: Enabling device 0001:00:1b.0 (0000 -> 0002) >>>Machine check in Kernel mode >>>Caused by (from SRR1=149030): Transfer error ack signal >>>Oops: machine check, sign: 7[#1] >>>................. >>>.................... >>>................. >>>Kernel panic -not syncing: Aiee, killing interrupt handler! >>> >>> >>Was it happening in the USB interrupt handler ? (the call backtrace >>should be appended to the Oops message). If yes, it's indeed yet another >>USB breakage (we are getting used to those ones). >> >>Ben. >> >> >> >> >> > > > > Hi, just for the record, i had the same thing here this morning. Linux kaluha 2.6.14 #1 PREEMPT Mon Oct 31 10:28:22 CET 2005 ppc GNU/Linux processor : 0 cpu : 7447/7457, altivec supported clock : 612MHz revision : 0.1 (pvr 8002 0101) bogomips : 406.52 machine : PowerBook5,2 motherboard : PowerBook5,2 MacRISC3 Power Macintosh detected as : 287 (PowerBook G4 15") pmac flags : 0000001b L2 cache : 512K unified memory : 768MB pmac-generation : NewWorld
-- Charles-Edouard Ruault +33 1 55 34 76 65 [EMAIL PROTECTED] Idtect SA 37 Bd des Capucines 75002 Paris, France www.idtect.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
