Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Jul 2006 14:49:29 -0600 (MDT)
From:      Warner Losh <>
Subject:   Re: if_re does not work
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
> > > In theory the bus_alloc_resource(.., SYS_RES_IRQ, ...) should route an 
> > > interrupt for the re0 device but it won't show up in the probe line in that 
> > > case since the probe line is printed before re_attach() is called.  In fact,
> > > in the failing case, it wasn't bus_alloc_resource() that failed, but
> > > bus_setup_intr().  This is most likely not an re0 issue however.
> > > 
> > > goto-san, can you add printf's to i386/i386/intr_machdep.c:intr_add_handler()
> > > and kern/kern_intr.c:intr_event_add_handler() to see which of the EINVAL
> > > cases is being triggered?
> > 
> > I added printf() to 2 functions (one in intr_add_handler() and two
> > in intr_event_add_handler()) and re-build my kernel and reboot my
> > ThinkPad X40. But I could not get any printf's messages.
> > 
> > And I have a question. Why INTR_FAST was added in re_attach()?
> > When I deleted it and re-build if_re modules, my card was attached.
> INTR_FAST added because the driver was converted to use 'fast' interrupts.
> I really hope nobody's going to tell me that INTR_FAST isn't supported with
> cardbus.

INTR_FAST isn't supported with cardbus at the moment.

However, that decision dates from a time when you couldn't share fast
and non-fast interrupts.  Cardbus necessarily shared its function
interrupt with its card status change interrupt (since there's only
one interrupt pin on the cardbus bridge).  I'll investigate what it
takes to make this happen given the current new-world order.  I have
at least one re cardbus card, I think, so I can do testing.


Want to link to this message? Use this URL: <>