Re: [PATCH/RFC] I/O-check interface for driver's error handling

From: Jesse Barnes (jbarnes_at_engr.sgi.com)
Date: 03/03/05

  • Next message: Jeff Garzik: "Re: RFD: Kernel release numbering" 
    To: linux-pci@atrey.karlin.mff.cuni.cz
Date:	Wed, 2 Mar 2005 15:40:09 -0800

    On Wednesday, March 2, 2005 3:30 pm, Linas Vepstas wrote:
    > Put it another way: a device driver author should have the opportunity
    > to poll the pci bus status if they so desire. Polling for bus status
    > on ppc64 is real easy. Given what Jesse Barnes was saying, it sounded
    > like a simple (optional, the dev driver doesn't have to use it) poll
    > is not enough, because some errors might be transactional.

    Yeah, I'm not arguing against your call, it could be useful for polling for
    errors or for use in an error handling callback. What I was trying to say
    earlier (maybe I wasn't very clear) was that the idea of creating
    transactions for certain types of I/O (even if those transactions are
    artificial and purely in software) can be useful since it creates boundaries
    and context, making it easier to figure out what went wrong, hopefully making
    it easier to fix things and carry on.

    IOW, using Seto-san's iochk_clear/iochk_read interface makes certain types of
    errors much easier to deal with since you *know* where an error occurred and
    can presumably deal with it right away. The problem comes in for things that
    aren't well encapsulated, like DMA, for which error polling or some sort of
    callback is needed (and even with polling you'll need to poll in an error
    handling thread as you mentioned since the driver may start DMA, return, and
    the error can happen later when we're not actually in driver code). So I
    think we mostly agree on what things need to be done, you and benh just have
    to fight it out over the details. :)

    Jesse
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Jeff Garzik: "Re: RFD: Kernel release numbering"

    Relevant Pages

    • Re: Better polling solution in wince driver
      ... I am implementing a touchpad driver using polling mechanism. ... So the only way to get the data is to poll the device every fixed time interval. ... The answer to my question was to use Sleep() ...
      (microsoft.public.windowsce.platbuilder)
    • tty_ldisc_try_get(): BUG kmalloc-8: Poison overwritten
      ... some sort of slab corruption going on in tty data structures: ... It's a single bit corruption - but the hardware in question has a ... 5f0878a: tty: Fix oops when scanning the polling list for kgdb ... # Generic Driver Options ...
      (Linux-Kernel)
    • Re: fxp0: device timeout | SCB already complete (me too)
      ... In my case, both the SCSI and NIC are integrated on the motherboard, so I ... Also, as I mentioned, I tried a de0 (PCI card, not onboard, and it ... > The boxes work just fine with the xl0 driver. ... This happens both with or without POLLING ...
      (freebsd-net)
    • Re: your mail
      ... To compile this driver as a module, ... * GNU General Public License for more details. ... * The touch position structure. ... * if interrupt isn't in use the touch positions can reads by polling ...
      (Linux-Kernel)
    • RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
      ... Polling For 100 mbps Connections? ... >>from the network into the ethernet receiver. ... not in the ethernet driver code. ... >NetGear cards using the dc driver or DLink cards using the rl driver. ...
      (freebsd-questions)