Re: 2.6.7-mm1 PCNet Problems under VMWare 4.5.2

From: Petr Vandrovec (VANDROVE_at_vc.cvut.cz)
Date: 06/23/04

  • Next message: Andy Whitcroft: "Re: [PATCH] consolidate in kernel configuration"
    To: Keith Moore <keithmo@exmsft.com>
    Date:	       Wed, 23 Jun 2004 16:26:52 +0200
    
    

    On 23 Jun 04 at 11:23, Keith Moore wrote:
    > - /* Clear any other interrupt, and set interrupt enable. */
    > - lp->a.write_csr (ioaddr, 0, 0x7940);
    > + /* Set interrupt enable. */
    > + lp->a.write_csr (ioaddr, 0, 0x0040);
    >
    > Reverting this one section of the patch makes eth0 happy again.
    >
    > I poked around with the values written to the csr register, and it
    > appears the virtual PCNet-II adapter needs bit 0x0100 (initialzation
    > done) set. So, writing 0x0140 instead of 0x0040 seems to work well.
    >
    > I have no idea how accurate VMWare's emulation of this adapter is, or if
    > this change may cause problems with other (physical) adapters.

    I believe that it is not emulation bug. What happens is that you do not
    confirm INIT DONE irq, causing endless stream of interrupts from card to
    the CPU. This happens because CSR3 default value is 0 (enable all
    interrupts), and driver does not modify it in any way (f.e. for
    preventing INIT from causing interrupt). So when init is done, IDON
    irq fires. In old driver it was acked by 0x7940 (or by 0x0140 in your
    modified driver), but in new driver it is not acked in any way,
    triggering this very same IRQ over and over.

    pcnet32_interrupt should loop while csr0 contains some pending
    interrupts (current mask 0x8600 should be changed to 0xDE00 to be 100%
    sure that all interrupts we handle in loop are catched), and then
    clear all other interrupts sources (0x2140) out of the loop.

    Other possibility is masking these unused sources in CSR3...

    But I believe that driver from -mm1 will hang even on real Am79C970A
    hardware.
                                                Best regards,
                                                    Petr Vandrovec
                                                    

    -
    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: Andy Whitcroft: "Re: [PATCH] consolidate in kernel configuration"

    Relevant Pages

    • [PATCH 2.6.16] Shared interrupts sometimes lost
      ... wireless cards - based on the RaLink 2560 chip set. ... This is using the "legacy" rt2500 driver derived from the vendor ... But Linux is definitely implicated in the loss of interrupts. ... This is my first real introduction to the IRQ handling code in Linux, ...
      (Linux-Kernel)
    • Re: PCI PM: Restore standard config registers of all devices early
      ... the driver or the driver calls pci_enable_device. ... that stage in the suspend process (and the GFP_KERNEL -> NOIO should probably ... I like the "loop of disable_irq" idea, with a few modifications. ... was written with the assumption that interrupts will be off in certain places, ...
      (Linux-Kernel)
    • Re: unexpected IRQ trap at vector
      ... Basically a device on IRQ 12 is spamming you with interrupts, ... recognized and asked to do so by a driver. ... Marvell NIC using the sky2 driver doesn't come up at boot, ...
      (Fedora)
    • Re: [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel
      ... device to have its final IRQ routing established. ... > In kdump, sometimes, general driver initialization issues seems to be cropping ... > not expecting any interrupts yet. ... > is booting and kernel disables that irq line. ...
      (Linux-Kernel)
    • Re: [PATCH] Prevent nested interrupts when the IRQ stack is near overflowing v2
      ... point to run those handlers with IRQs enabled at all? ... I think the idea was to minimize irq latency for other interrupts ... such a driver is broken by ...
      (Linux-Kernel)