hme problems

[Gallagher, James]

> -----Original Message-----
> From: Marius Strobl [mailto:marius at alchemy.franken.de] 
> Sent: Thursday, October 13, 2005 18:15 PM
> To: Gallagher, James
> Cc: 'Ppop Door'; freebsd-sparc64 at freebsd.org
> Subject: Re: hme problems
> 
> 
> On Thu, Oct 13, 2005 at 04:26:29PM +0800, Gallagher, James wrote:
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: owner-freebsd-sparc64 at freebsd.org
> > > [mailto:owner-freebsd-sparc64 at freebsd.org] On Behalf Of Ppop Door
> > > Sent: Thursday, October 13, 2005 16:06 PM
> > > To: freebsd-sparc64 at freebsd.org
> > > Subject: hme problems
> > > 
> > > 
> > > Greetings,
> > > 
> > > We have an E250, trying to put 5.4R on it, and we get
> > > this:
> > > hme0: Ethernet address: 08:00:20:e7:16:88
> > > hme0: couldn't establish interrupt
> > >  
> > > Consequently, no hme0 device is available later on for ifconfig.
> > > 
> > > Card and box were working fine as Solaris.
> > > 
> > > Any help, solutions?
> > > 
> > > 
> > Hi,
> > 
> > No solution that I'm aware of - I asked this question also 
> awhile back
> > 
> (http://lists.freebsd.org/pipermail/freebsd-sparc64/2005-April/002973.
> > html)
> > also as I encountered the problem going from 5.3 to 5.4. I 
> should have a
> > look at it again and try to report the issue properly (once 
> I dig around in
> > the Handbook and figure out what that way is!)
> 
> That's an old bug; the second NS16550 (used as mouse port) on 
> E250 erroneously gets the IRQ of the on-board HME assigned. 
> Later on this became fatal when uart(4) was enabled which 
> began trying to use that NS16550. The attached patch (applies 
> to HEAD and RELENG_6 but it should also be fine to just grab 
> uart_bus_ebus.c from HEAD, apply the patch and stick it into 
> a FreeBSD 5 system) should work around this by causing 
> uart(4) to not attach to the NS16550 in question in favour of 
> a working on-board HME. AFAICT the underlying problem is 
> caused by a IRQ routing problem due to interpreting the 
> information present in OFW wrong. This however can happen at 
> a couple of layers (the exact code path is also model 
> dependend) and I didn't manage to spot faulty code. Fixing it 
> would require me to have at least remote access to an E250 
> which so far I didn't manage to get. Also currently I'm short 
> on spare time...
> 
> Marius
> 
> 
Thanks Marius, I'll look at getting this patch on and see how I go. 

Sadly I can't offer any access to the E250s we have here as they're not
permanently connected to the internet (only for updates).

Regards,
James