Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Nov 2000 11:44:27 -0800 (PST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Bernd Walter <ticso@cicely8.cicely.de>
Cc:        freebsd-alpha@FreeBSD.org
Subject:   RE: AST and ithread question
Message-ID:  <XFMail.001113114427.jhb@FreeBSD.org>
In-Reply-To: <20001112173709.B5667@cicely8.cicely.de>

next in thread | previous in thread | raw e-mail | index | archive | help

On 12-Nov-00 Bernd Walter wrote:
> As far as I underderstood an AST is needed for context switching.
> An AST can only happen before returning to user-mode.
> Which process is running in user-mode during kernel initialisation.
> How can the context switched to an scsi-controller ithread during
> the first scsi-probe?

The SCSI probe is done during SI_SUB_INT_CONFIG_HOOKS.  Note that the timeouts
to manage the roundrobin scheduler are started just before this in
SI_SUB_KICK_SCHEDULER.  During the probes on the SCSI bus and the ATA bus, the
kernel code calls tsleep() to wait for the interrupts to come in.  The CPU then
spins in the idle process loop (sys/kern/kern_idle.c:idle_proc()), which calls
mi_switch() as soon as a process becomes runnable (such as when an interrupt
occurs and schedules an interrupt thread to run).  Each interrupt thread runs
to completion, and then calls mi_switch() to run either the next interrupt
thread, the just-awakened() proc0 that did the tsleep() (if the handler did a
wakeup()), or to go back into the idle process.

> I can see that there are getting clock swi scheduled and processed.
> after the 15 second period after scsi-reset I see from one or more
> controllers an interrupt and the connected ithread is set to the
> run-queue.
> No ithread including the clock is running after that.
> The clock is still geting scheduled.

The clock is not handled via a thread, it is run directly.

> I tried to remove this AST limitation but this doesn't work as the
> kernel hangs during clock initialisation.
> I also tried to reduce it to gd_intr_nested_level==0

Removing the AST limitation would make our kernel pre-emptive, which it is not
designed to be. :)  Only userland is pre-emptive in FreeBSD atm.

> Possibly the console output from KTR changes the situation as I'm
> running on a 9600 seriel.
> Does anyone know how I can change this to a higher rate?
> If neccesary I will add some sio devices to separate kernel and SRM
> output.
> 
> -- 
> B.Walter              COSMO-Project         http://www.cosmo-project.de
> ticso@cicely.de         Usergroup           info@cosmo-project.de

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001113114427.jhb>