Debugging driver modules

Debugging driver modules

[Scott Bahling]

Hello-

I have a STAudio DSP24 mkII and I have noticed that recent changes(after
NOV 13) in the CVS creates an ICE1712 driver that locks up my kernel.
Instead of just complaining about this problem I thought I might try to
narrow down the location in the driver that is causing the lockup.

Does anyone have any tips on debugging the driver modules? Is anyone
using a debugger to do this? I have looked at UML, but I am not sure if
there is a way to access the sound hardware with it.

Thanks,

scott



-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en

Re: Debugging driver modules

[Paul Davis]

>I have a STAudio DSP24 mkII and I have noticed that recent changes(after
>NOV 13) in the CVS creates an ICE1712 driver that locks up my kernel.
>Instead of just complaining about this problem I thought I might try to
>narrow down the location in the driver that is causing the lockup.
>
>Does anyone have any tips on debugging the driver modules? Is anyone
>using a debugger to do this? I have looked at UML, but I am not sure if
>there is a way to access the sound hardware with it.

use the "single" kernel option on the boot command line. this will
shorten start up times considerably. once you're at the shell prompt,
mount any necessary filesystems by hand, modprobe the drivers, and
test using a console window. i generally find that this shortens the
crash-reboot-edit-recompile-reboot-crash cycle by a factor of at least
three. mount any filesystems that don't need to be writable with the
"ro" option so that any crash leaves them untouched.

the debugging process i use for drivers and real-time threads makes
heavy use of binary search and print{k,f}

--p


-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en

Re: Debugging driver modules

[Matthias Weiss]

On Sat, Nov 30, 2002 at 12:38:20PM -0500, Paul Davis wrote:
> >I have a STAudio DSP24 mkII and I have noticed that recent changes(after
> >NOV 13) in the CVS creates an ICE1712 driver that locks up my kernel.
> >Instead of just complaining about this problem I thought I might try to
> >narrow down the location in the driver that is causing the lockup.
> >
> >Does anyone have any tips on debugging the driver modules? Is anyone
> >using a debugger to do this? I have looked at UML, but I am not sure if
> >there is a way to access the sound hardware with it.
> 
> use the "single" kernel option on the boot command line. this will
> shorten start up times considerably. once you're at the shell prompt,
> mount any necessary filesystems by hand, modprobe the drivers, and
> test using a console window. i generally find that this shortens the
> crash-reboot-edit-recompile-reboot-crash cycle by a factor of at least
> three. mount any filesystems that don't need to be writable with the
> "ro" option so that any crash leaves them untouched.

Couldn't "user mode linux" be used to avoid the "reboot" stage?

matthias


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Debugging driver modules

[Takashi Iwai]

At 30 Nov 2002 16:27:43 -0600,
Scott Bahling wrote:
> 
> Hello-
> 
> I have a STAudio DSP24 mkII and I have noticed that recent changes(after
> NOV 13) in the CVS creates an ICE1712 driver that locks up my kernel.
> Instead of just complaining about this problem I thought I might try to
> narrow down the location in the driver that is causing the lockup.
 
can you confirm the date when the critical change was applied to cvs?
the driver before Nov. 13 works really?

if so, you can make a diff between these two versions and find out
which change causing the lock up.


> Does anyone have any tips on debugging the driver modules? Is anyone
> using a debugger to do this? I have looked at UML, but I am not sure if
> there is a way to access the sound hardware with it.

AFAIK, UML is not possible for such a low-level driver, because it
needs the direct i/o access.
other kernel debuging tools might be useful, e.g. strack-tracing via
alt-sysrq.  i cannot tell much about them since i've not used, too.

also, if the problem is a dead spinlock, you can try the kernel with 
SPINLOCK_DEBUG flag to find the culprit.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Debugging driver modules

[Takashi Iwai]

At Mon, 02 Dec 2002 10:35:57 -0600,
Scott Bahling wrote:
> 
> Takashi Iwai wrote:
> 
> >At 30 Nov 2002 16:27:43 -0600,
> >Scott Bahling wrote:
> >  
> >
> >>Hello-
> >>
> >>I have a STAudio DSP24 mkII and I have noticed that recent changes(after
> >>NOV 13) in the CVS creates an ICE1712 driver that locks up my kernel.
> >>Instead of just complaining about this problem I thought I might try to
> >>narrow down the location in the driver that is causing the lockup.
> >>    
> >>
> > 
> >can you confirm the date when the critical change was applied to cvs?
> >the driver before Nov. 13 works really?
> >  
> >
> Actualy the changes happened on the 14th. I have a copy of the cvs 
> tarball from the 13th and the drivers work fine. According to the CVS 
> web interface, on the 14th Jaroslav "Added rate reset & locking for 
> pro-pcm and added internal rate setup"

hmm, does the lock occurs even if you don't register
snd_ice1712_pro_internal_clock control (ice1712.c line 2243) ?
other changes seem harmless...


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf