Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: mutex_unlock | Date | Wed, 9 Apr 2008 22:40:25 +0200 |
| |
On Wednesday, 9 of April 2008, Justin Mattock wrote: > Hello with testing out git(very cool); my first test was with > 2.6.25-rc8-00194-g4cac04d ran vary smoothly; > then I decided to pull the latest git (2.6.25-rc8-00208-g7180c4c)and > see what I might find. > upon reboot the system starts up giving me this: > > Starting up > Decompressing Linux Done > Booting the kernel > __ <-------blinking > > I waited a few seconds or minutes but nothing; > after reading earlier posts about something with a mutex_unlock maybe > this was what I was experiencing. > when loading a live cd and recompiling the same kernel, I noticed > under kernel hacking; > > RT Mutex debugging > Built in scriptable tester for rt-mutexes > Spinlock and rw-lock debugging > Mutex debugging basic checks > Lock debugging detect incorrect freeing of live locks > Lock debugging prove locking correctness > lock usage statistics > Lock dependency engine debugging > spinlock debugging sleep-inside-spinlock checking > Locking API boot-time self-tests > > With not knowing what I was doing I chose yes to all of these options, > then reboot -f, > The system booted up properly, > > Is there a way where I can find out if this was what was going on? > could this be something different?
Hm, interesting.
It looks like our locking debugging code may hide some issues ...
Thanks, Rafael
| |