=================================
[ INFO: inconsistent lock state ]
2.6.22 #1
---------------------------------
inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
  (&rp->lock){++..}, at: [<f8c890db>] rhine_tx_timeout+0x6f/0xf4 [via_rhine]

this is a case of homegrown locking: the via-rhine driver does

        /* protect against concurrent rx interrupts */
        disable_irq(rp->pdev->irq);

        spin_lock(&rp->lock);

        /* clear all descriptors */
        free_tbufs(dev);
        free_rbufs(dev);
        alloc_tbufs(dev);
        alloc_rbufs(dev);

        /* Reinitialize the hardware. */
        rhine_chip_reset(dev);
        init_registers(dev);  

        spin_unlock(&rp->lock);
        enable_irq(rp->pdev->irq);


as a way to protect code against interrupts... rather than using the
normal mechanism.


the annotation is pretty simple (untested, not even compiled):

--- linux-2.6.22/drivers/net/via-rhine.c.org	2007-07-31 14:22:06.000000000 -0700
+++ linux-2.6.22/drivers/net/via-rhine.c	2007-07-31 14:22:26.000000000 -0700

@@ -1191,7 +1191,7 @@
 	       mdio_read(dev, rp->mii_if.phy_id, MII_BMSR));
 
 	/* protect against concurrent rx interrupts */
-	disable_irq(rp->pdev->irq);
+	disable_irq_lockdep(rp->pdev->irq);
 
 	spin_lock(&rp->lock);
 

@@ -1206,7 +1206,7 @@
 	init_registers(dev);
 
 	spin_unlock(&rp->lock);
-	enable_irq(rp->pdev->irq);
+	enable_irq_lockdep(rp->pdev->irq);
 
 	dev->trans_start = jiffies;
 	rp->stats.tx_errors++;