Re: Richtig debuggen, aber wie?

On Tue, Mar 04, 2003 at 01:00:35PM +0100, Ulrich Spoerlein wrote:
> On Tue, 04.03.2003 at 12:32:32 +0100, Bernd Walter wrote:
> > > Hmmm, ktrace ist nicht weiter hilfreich:
> > > [...]
> > > 961 oss-test CALL ioctl(0x3,SNDCTL_DSP_SPEED,0xbfbff558)
> > > 961 oss-test RET ioctl RESTART
> > > 961 oss-test CALL ioctl(0x3,SNDCTL_DSP_SPEED,0xbfbff558)
> > > 961 oss-test PSIG SIGINT SIG_DFL
> >
> > Bleibt der im ersten ioctl stehen?
> > Wenn ja, dann ist das ein Kernelfehler im Treiber.
> > Ein kdump -T wäre gut.
>
> Nein, das ist der (eigentlich) letzte ioctl(), ich setze nacheinander 8,
> 11, 22, 24, 32, 48 und 96kHz. Bei 96kHz stoppt er (auch wenn ich _nur_
> 96kHz setze). Ich bin mir ziemlich sicher, dass es mit meiner Live! zu
> tun hat, kann mir aber nicht vorstellen, dass es ein Hardware Fehler
> ist, dann unter -CURRENT laeuft es.

Das beantwortet nicht die Frage.
Ich sehe, das der mit einem ioctl in den Kernel geht und aufgrund des
CTRL-C zurückkehrt.
Ich sehe aber nicht, ob der im Kernel festgehangen hat, weil die Zeit-
daten fehlen.

> > > Btw, unter -CURRENT laeuft das Programm "einwandfrei" durch, mal
> > > abgesehen von den "Could sleep with lock..."
> >
> > IIRC kann -current Bitraten wandeln.
>
> Wie genau soll das funktionieren? Ich fordere 96kHz an und er meldet OK
> zurueck, wandelt aber heimlich auf zB 44kHz runter? Dieses Verhalten
> wuerde ich nich gut finden.

Warum nicht?
Warum sollte jede Anwendung eigene Funktionen dafür mitschleppen?

> Aber zurueck zu ioctl(), wie kann ich nachsehen wo ioctl() haengt? Im
> Kernel?

Im Treiber Source.
Es gibt eine Liste vom Typ struct cdevsw mit Einstiegsfunktionen,
unter anderem auch eine für die Behandlung von ioctls.
In dieser mußt du suchen.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message