Date: Tue, 01 Dec 1998 21:02:38 -0800 From: Mike Smith <mike@smith.net.au> To: Bruce Evans <bde@zeta.org.au> Cc: geoffb@demon.net, mike@smith.net.au, andyf@speednet.com.au, freebsd-current@FreeBSD.ORG, johan@granlund.nu, ortmann@sparc.isl.net Subject: Re: sio breakage Message-ID: <199812020502.VAA02814@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 01 Dec 1998 14:30:14 %2B1100." <199812010330.OAA20453@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> I was assuming the serial interface which is a fixed one breaking out of
> >> the back of the Laptop had nothing to do with the PCMCIA,
> >
> >You're quite correct; it doesn't. There's *something* holding up both
> >your interrupt handlers and the tty soft interrupt; maybe even possibly the
> >same thing that causes the "calcru: negative time for ..." messages.
>
> something()
> {
> asm("cli");
> asm("sti");
> }
>
> This disables interrupts for 0 user instructions, but if a pagefault
> occurs for reading the "sti" instruction, it disables interrupts for
> hundreds, thousands or millions of kernel instructions.
Since 'cli' can't be executed in user space, and a page fault in kernel
mode is a fatal occurrence, this can't happen.
> something_more_likely()
> {
> asm("cli");
> var = 0;
> asm("sti");
> }
>
> This disables interrupts for 1 or 2 user instructions, but if a pagefault
> occurs for reading a critical instruction or more likely for accessing
> the variable, it disables interrupts for hundreds, thousands or millions
> of kernel instructions.
Again, since 'cli' can't be executed in kernel space, this is only an
issue within the kernel. I'm not aware of any code which calls the
fu*/su*/copy* family with interrupts disabled - perhaps a trivial
wrapper could be installed to check for this?
> Fixes:
> kernel: send a fatal signal to applications that do this.
We have one already; it's called SIGBUS.
> applications: don't do this. If interrupts must be disabled, then all
> critical code and data must be within one page.
They can't (short of getting PSL_IOPL and then manipulating the PIC
themselves), so this isn't an issue.
Failure to deliver interrupts in the kernel seems to be a persistent
problem; it's almost certainly the problem with these sio errors, and
Poul seems to think it's responsible for breaking his code as well.
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mike@smith.net.au
\\ The race is long, and in the \\ msmith@freebsd.org
\\ end it's only with yourself. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812020502.VAA02814>