Re: hard lock using combination of devices

From: Carl Thompson (cet_at_carlthompson.net)
Date: 02/17/04

  • Next message: Martin Waitz: "Re: [RFC][PATCH} 2.6 and grsecurity" 
    Date:	Tue, 17 Feb 2004 06:14:00 -0800
To: vda <vda@port.imtp.ilyichevsk.odessa.ua>

    Quoting vda <vda@port.imtp.ilyichevsk.odessa.ua>:

    > On Tuesday 17 February 2004 09:14, Carl Thompson wrote:
    >> Quoting vda <vda@port.imtp.ilyichevsk.odessa.ua>:
    >> > ...
    >> >
    >> > Your box share IRQs in a big way :)
    >>
    >> Your point?
    >
    > While shared interrupts can in theory work right,
    > lots of hardware and/or drivers do not handle
    > that.

    First, the two devices in question are not on the same interrupt. Second, it
    is very difficult in this day in age to build a system without interrupt
    sharing. While I agree that it's better to have as few devices sharing as
    possible, there are simply too many devices in modern systems and too few
    interrupts. Interrupt sharing needs to work on modern hardware and needs to
    work in Linux. This notebook is pretty typical in its interrupt distribution
    and I'm not certain that this is a problem. In fact, while many devices on
    this system use IRQ 11 the only one active at the time was the audio
    controller. And while IRQ 10 is shared between the CardBus adapters and the
    video card the problems still occur if I don't run X and video interrupts
    shouldn't be generated in console mode, right?

    > I think you should try to reconfigure your
    > system so that devices do not share same IRQ
    > and see whether that 'fix' the problem.

    There are no options in my notebook's BIOS to reconfigure interrupts or
    disable
    devices.

    > BTW, can you show your /proc/interrupts ?

    Attached.

    > --
    > vda

    Carl Thompson

    -
    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: Martin Waitz: "Re: [RFC][PATCH} 2.6 and grsecurity"

    Relevant Pages

    • Re: timing code in 2.6.1
      ... The hardware doesn't produce an interrupt ... For medical equipment which affects patient safety, ... These will produce interrupts. ... very likely that you need accurate and consistent time intervals ...
      (Linux-Kernel)
    • Re: [Fastboot] Re: [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel
      ... >> you don't reassign IOMMU entries at least). ... >> the hardware, as if all interrupts are shared. ... I guess there could be a problem with drivers ...
      (Linux-Kernel)
    • Re: Stopping execution
      ... ages" of the 8 bit 8085, I understood something about interrupts. ... That driver tells the OS that a hardware event has ... certain system event" slow down the acutal execution of a bit of code ... slowdown due to the OS' kernel having to do something. ...
      (microsoft.public.vc.language)
    • Re: Help on: How to avoid placing millions of software checkpoints
      ... I have a programming problem/challenge. ... is responsible for handling hardware. ... The problem arises when the hardware receives a "stop command". ... Using interrupts doesn't seem to help me ...
      (comp.lang.c)
    • Re: [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel
      ... > In general generic hardware bits for disabling DMA, ... > you don't reassign IOMMU entries at least). ... > the hardware, as if all interrupts are shared. ...
      (Linux-Kernel)