Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 07 Oct 2000 01:18:15 +0100
From:      ian j hart <ianjhart@freeloader.freeserve.co.uk>
To:        John Reynolds~ <jreynold@sedona.ch.intel.com>
Cc:        "stable@freebsd.org" <stable@freebsd.org>
Subject:   Re: breakage with two ed network devices
Message-ID:  <39DE6BC7.DDCAD907@freeloader.freeserve.co.uk>
References:  <14812.58143.609625.133015@hip186.ch.intel.com> <A0E035400B00D4118F9E0008C70D4D77A88A@ITC1> <200010051637.KAA51557@harmony.village.org> <200010060408.WAA05189@harmony.village.org> <200010061618.MAA07034@world.std.com> <200010061722.NAA13450@world.std.com> <200010061947.PAA17583@world.std.com> <14814.12910.409342.160241@hip186.ch.intel.com>

next in thread | previous in thread | raw e-mail | index | archive | help
John Reynolds~ wrote:
> 
> [ On Friday, October 6, Kenneth W Cochran wrote: ]
> >
> > >I've thought of that too ... but I think Warner stumbled
> > >upon the correct answer. To me, there's not much of a reason for the
> > >ATA code to probe and attach (and hog IRQ15) for ata1 when I
> > >
> > > a) don't have it configured in my kernel
> > > b) don't have anything sitting on that channel
> > >
> > And I'm Very Inclined To Agree With Warner.  :)
> > (Although I am curious to know what happens(ed) if IRQ15
> > (2nd ATA port) is BIOS-disabled...)
> >
> 
> Well, curiosity killed the cat. It also killed my machine (not quite). On many
> people's advice I went home at lunch and disabled the second IDE channel in my
> BIOS altogether. Now when I boot a 4.1.1-S kernel (verbose) I get:
> 
>   ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xf000
>   ata0: mask=03 status0=50 status1=00
>   ata0: mask=03 status0=50 status1=00
>   ata0: devices = 0x1
>   ata0: at 0x1f0 irq 14 on atapci0
>   ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xf008
>   ata1: mask=00 status0=ff status1=ff
>   ata1: probe allocation failed
> 
> And, not only that, but now I see that ed0 attaches!
> 
>   ed0 at port 0x2c0-0x2df iomem 0xd8000 irq 15 on isa0
>   bpf: ed0 attached
>   ed0: address 00:40:05:6e:67:c0, type NE2000 (16 bit)
>   ed1 at port 0x340-0x35f iomem 0xd8000 irq 9 on isa0
>   bpf: ed1 attached
>   ed1: address 00:40:05:6e:67:9c, type NE2000 (16 bit)
> 
> BUT ... it didn't quite solve the problem. After the filesystems were mounted
> and the machine fired up DHCP to configure ed0 with its address, I kept
> getting these error messages until I hit ^C:
> 
>   ed0: device timeout
>   ed0: device timeout
>   ed0: device timeout
>   ed0: device timeout
>   ed0: device timeout
> 
> The rest of the machine booted of course, but ed0 was "dead." This means the
> device isn't getting any interrupts, correct? This is still with
> 
>  device  ata0  at isa? port IO_WD1 irq 14
> 
> in my kernel and not just "device ata". It also happens when I boot my
> working 4.1-RELEASE kernel (the ed0: device timeout messages). When I go back
> into the BIOS and re-enable the second IDE channel then and only then can I
> even use my 4.1-R kernel "like before."
> 
> Aside from changing the bloody IRQ on my first NIC, what else can be tried?
> 
> -Jr

This may not be relevant, but here are a few points of reference (0.2
euro worth).

case 1: PCI NE2000 clone (asix, rtk8039 I think) on ed driver

This card wouldn't probe at all without setting user config (GENERIC 4.1
kernel) as follows. Delete all other NIC drivers. Set i/o to 0xEF80. I
got the i/o address from the DOS setup program (useful). Deleting the
other drivers has been mentioned in the list I think.

case 2: PCI Ovislink RTK8139, SB128PCI?, AZZA VIA Apollo MVP3 M/B

The two cards would clash unless the BIOS was set to PNP resources
controlled by AUTO. This prevents setting IRQ 15 to legacy of cource.
This is a BIOS issue. The cards are hosed before you even boot.

Don't overlook the obvious. If you moved the box then Murphy's Law
states that
* Six years worth of dirt fell into the connector.
* The Network cable failed.
* The new hub doesn't duplex, but the driver thinks it does.

These all give the symptom that the card probes okay, but DHCP fails.
Equally I've had M/B's where disabling the PS2 mouse disabled interrupts
on IRQ 12. You could have the same thing with IRQ 15.

If you don't need the second serial port, turn it off. That gets you a
very useful IRQ to play with. I would avoid IRQ 15 like the plague (and
12 for that matter).

What happens if you swap the IRQ's of the cards, or swap the order of
the cards in rc.conf? Are both cards using DHCP? I've never gotten two
cards to work like this. The second one fails - this could be me tho' ;)

HTH/Prods the brain cells/Doesn't confuse the issue to much.

-- 
ian j hart


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39DE6BC7.DDCAD907>