From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: David T Eger <eger@cc.gatech.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PCI Power Management / Interrupt Context
Date: Wed, 27 Jun 2001 00:00:58 -0400 [thread overview]
Message-ID: <3B395A7A.848908C@mandrakesoft.com> (raw)
In-Reply-To: <Pine.SOL.4.21.0106262208240.3824-100000@oscar.cc.gatech.edu>
David T Eger wrote:
> when I read documentation (Documentation/pci.txt) which mentions that
> remove() can be called from interrupt context.
ignore that. You can sleep in remove, and it will not be called from
interrupt context.
> Reading code in my sister frame buffer devices, I see that
> unregister_framebuffer() can fail. I can easily see a nice happy console
> or user app diddling away on the framebuffer writing to the memory on the
> device, and then poof! someone yanks the card, processor takes an
> interrupt, and then... and then? what to do?
if someone yanks the card, how is it going to deliver an interrupt to
the CPU?
> In fact, here's an interesting snippet from cyber2000fb.c:
>
> static void __devexit cyberpro_remove(struct pci_dev *dev)
> {
> struct cfb_info *cfb = (struct cfb_info *)dev->driver_data;
>
> if (cfb) {
> /*
> * If unregister_framebuffer fails, then
> * we will be leaving hooks that could cause
> * oopsen laying around.
> */
> if (unregister_framebuffer(&cfb->fb))
> printk(KERN_WARNING "%s: danger Will Robinson, "
> "danger danger! Oopsen imminent!\n",
> cfb->fb.fix.id);
> cyberpro_unmap_smem(cfb);
> cyberpro_unmap_mmio(cfb);
> cyberpro_free_fb_info(cfb);
>
> /*
> * Ensure that the driver data is no longer
> * valid.
> */
> dev->driver_data = NULL;
> if (cfb == int_cfb_info)
> int_cfb_info = NULL;
> }
> }
>
> So, umm, is there a consensus on what to do if someone currently expects
> to be writing to memory that doesn't exist any more?
huh? what are you talking about? oops or random memory corruption
occurs. there is no consensus necessary.
If you are worried about unregister_framebuffer failure, then don't
deallocate the memory, or sleep until unregister_framebuffer succeeds,
or any one of a number of workarounds.
Jeff
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024 |
MandrakeSoft |
next prev parent reply other threads:[~2001-06-27 4:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-27 2:42 PCI Power Management / Interrupt Context David T Eger
2001-06-27 4:00 ` Jeff Garzik [this message]
2001-06-27 11:22 ` Alan Cox
2001-06-27 11:20 ` Alan Cox
2001-06-27 18:41 ` Linus Torvalds
[not found] ` <200106271841.f5RIfR432746@penguin.transmeta.com>
2001-06-27 18:49 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B395A7A.848908C@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=eger@cc.gatech.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox