semi-OT: how to backtrace into the kernel when it's stuck

[Danny Milosavljevic]

Hi,

Am Mittwoch, den 14.12.2005, 10:56 -0500 schrieb David Zeuthen:
> On Wed, 2005-12-14 at 16:04 +0100, dannym wrote:
> > Hi,
> > 
> > this is kind of off-topic but ...
> > 
> > You know, I have this dvd drive...
> > 
> > when hald is running and I issue mount on the drive, mount will hang and
> > not let itself be killed by any means. (the mount will neither succeed
> > nor fail but will just be "halted")
> 
> Yes, both mount and one or more hald-addon-storage processes is in state
> D (uninteruptible IO), right?
> 
> (use ps aux to find the state)
> 
> > 
> > when hald is not running, it works fine.
> > 
> > Now I thought it would be nice if I could debug that and for that it
> > would be nice to see where in the kernel it is waiting around (for some
> > lock, I suppose) for that mount process.
> > 
> > Any ideas how to debug this on the hal side would be nice too :)
> 
> Well, a helper of hald is simply polling the drive so we can detect
> media changes and I believe the driver in the kernel gets very confused
> and somehow stops servicing IO from user-space processes. 

Yeah... 

I've been trying to get a clue how to debug kernel stuff, but so far, no
luck... (there are tons of howtos on how to debug oopses and whatnot,
but unfortunately, I don't get an oops...)

Can you point me to the hal helper source portion so I at least can
confirm that indeed it is part of the cause (by me creating a small
standalone prog that does the same things)?

> 
> The kernel shouldn't do this, I submit this is a bug with the kernel. To
> answer your question, no, I don't really know how to fix this, sorry.
> 
> Cheers,
> David
> 
> 

cheers,
  Danny