Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Oct 2000 13:22:49 -0400 (EDT)
From:      Kenneth W Cochran <kwc@world.std.com>
To:        John Reynolds~ <jreynold@sedona.ch.intel.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: breakage with two ed network devices
Message-ID:  <200010061722.NAA13450@world.std.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
>From owner-freebsd-stable@freebsd.org  Fri Oct  6 12:39:56 2000
>From: John Reynolds~ <jreynold@sedona.ch.intel.com>
>Date: Fri, 6 Oct 2000 09:35:51 -0700 (MST)
>To: Kenneth W Cochran <kwc@world.std.com>
>Cc: freebsd-stable@freebsd.org
>Subject: Re: breakage with two ed network devices
>
>[ On Friday, October 6, Kenneth W Cochran wrote: ]
>> Please pardon my "jumping in" and/or ignorance...
>> 
>> ed0 living on an IRQ that is "reserved" (somehow) for one
>> of the ATA "channels?"  (ie. 14 and/or 15?)
>
>Hmmmm. Yeah, I've got ed0 living on IRQ15. However, this h/w
>combo has been running since 3.3 (including 4.0->4.1-RELEASE).

I wonder if its "previous" running/probing might have been a
"glitch" (not as severe as a "bug" :) with prior drivers and
that now, this "glitch" is being "exposed" by the "new" stuff(?)

>> Hmmm...  I might "question" an ATA-probe "there..."  (?)
>> 
>> Can this card (ed0) go to a different IRQ?  Is that IRQ
>> disabled/reassigned (from PCI) in the BIOS/setup?
>
>No, it's hardwired in the card. I read on the archives when
>I bought it to disable the PnP stuff on the card because it
>wouldn't work without it. So, I assigned it IRQs manually
>through their stupid little DOG program. 15 and 9 were the
>only ones their setup program could find that weren't
>"conflicts" with something else.
>
>I can certainly try to move ed0 onto a different IRQ.

Maybe remove something & change the IRQ just for testing?
Is IRQ 15 BIOS-disabled (therefore making it available for
things like ISA cards).  Might be useful datapoints...

>> I might want to "move" this one, too; IRQ 9 is the "shared"
>> one & it has always "frightened" me some...  :)
>> 
>> (Brain-cobweb-digging)  I also notice that that the "iomem"
>> is the same; shouldn't those be different segments?
>
>Probably so. Any suggestions for the second segment's
>starting position? LINT says nothing about it.

Hmmm...  These cards appear to be "shared-memory" cards.

1.  IIRC (deep cobwebs now :), shared memory should not
(cannot?) be cached, thus the possible need to "enable" the
"memory hole" at 15M (in BIOS setup).  IIRC (again :) this
makes a 1mb non-cacheable "region" starting at 15M.

2.  We would need to know the "shared memory segment size"
of the cards & how to set their (starting) addresses (any
card -doc?); (conceivably) these would be values for
"iomem" in your kernel-config.  I couldn't find anything
about "iomem" either, but that would be my guess.
Hopefully Someone Who Knows will answer here (& maybe
document that parameter?  :)
(I see Warner replying...  ;)

>> Hope I was at least slightly helpful...
>
>yeah, it was at least enlightening to see that IRQ14/IRQ15
>are "meant" for ATA. That certainly does look like a
>smoking gun. However, I bring up the canonical fact that
>"it worked before this commit" ....

As I mentioned above, its "working before" miiiiight have
been a "glitch" (or maybe a "boo-boo" :).  But I'd think
that would be "cleared" if you "turn off" IRQ 15 in your
BIOS.  Fwiw, I run 4.1.1-s on a box so configured, & IRQ 15
gets used "elsewhere" (the (PCI) NIC at this time).

>Hopefully I'll have time over the weekend to futz with the
>IRQs on these cards. Maybe I'll just ditch the damn things
>and go get two PCI NICs ... who knows ...

I believe PCI NICs would be The Cure...  My experience with
(especially PnP) ISA cards on modern PCI systems leads me
to conclude that (ISA/PnP) cards are Truly Evil(tm)...

>Thanks,
>-Jr

I'm curious as to how it turns out...

-kc


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?200010061722.NAA13450>