Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Jul 1997 00:02:40 +0200 (CEST)
From:      Mikael Karpberg <karpen@ocean.campus.luth.se>
To:        imp@rover.village.org (Warner Losh)
Cc:        current@FreeBSD.org
Subject:   Re: I am contemplating the following change...
Message-ID:  <199707212202.AAA10525@ocean.campus.luth.se>
In-Reply-To: <E0wqNiO-0001wO-00@rover.village.org> from Warner Losh at "Jul 21, 97 01:01:48 pm"

next in thread | previous in thread | raw e-mail | index | archive | help

I'll just take to replys in one mail and save us all some spam...

According to Jordan K. Hubbard:
[What's wrong with having a double entry... ed0 and ed1]
> Because I think the basic idea we're trying to push with the whole
> userconfig thing (and its associated docs) are that you should always
> edit ed0 to match your card, whatever that might be, and if it falls
> to ed1 then something is _wrong_ and you should go back and edit the
> entry for ed0 again.
>
> Also, with the settings as they currently stand today, you rarely get
> fall back behavior which actually helps the user - far from it.  What
> happens instead is that ed1's port value matches but the IRQ value is
> still wrong, and while the user sees a "probe" for ed1 and an entry in
> all the relevant selection menus (further leading them to feel that
> things are fine), things hang up later when they actually go out and
> try to use the card.  Timeouts, hangs, very confused users.
>
> If, on the other hand, you didn't even show them an ethernet card as
> an option, nor did they see a probe message for it at boot time, it's
> be a strong indication to them that they need to go fix this problem
> first.  When the ed1: timeout problems happen, by contrast, they
> typically write to us since it's not a failure they understand.

Yeah, but there are a few things against this too:
  1) We get only one guess at their ethernet card's setting. If ed0 is not
     correctly set to 300/10 as it should, then their ethernet wont work
     without configuration.
  2) "a strong indication to them" is not much good, I think. The boot
     messages scroll by quite fast, and I'd think it looks more like
     annoying garbage text that you should ignore, just like you did on
     your DOS machine with 2000 copyrights and other garbage text from
     drivers loading. New users will be waiting for the machine to just boot,
     or possibly ask them something. That's my guess.
  3) It's not that easy to do the configuration, no matter how nice the
     UI is. There's only one really easy way for the user. Do it for him.
     This means probing... See the other mail...

------------------------------------------------------------------------

According to Warner Losh:
> Looking at the driver, the following chipsets seem to support auto
> detection of interrupts.  I've some patches that I'll test tonight to
> see if I can add a sanity check when things aren't the same.  I may
> have missed some in some of the other code paths.
> 
> 	WD8003W
> 	WD8003EB
> 	WD8013W
> 	WD8013EP
> 	WD8013WC
> 	WD8013EPC
> 	WD8013EBP
> 	SMC8216T
> 	SMC8216C
> 	SMC8216BT
> 
> I don't know how many cards this covers, but it does look to be a fair
> number.  There is code in the ed driver now to autoconfig the
> interrupt on these cards.  There is not code to detect that you've set
> an interrupt incorrectly (which looked like 3 lines to add in two
> places, add another 10 lines for tables needed for good error
> reporting).  I think that this would be a worthwhile addition to the
> kernel, assuming that it proves to be correct.

What?! There is code to autodetect it, but if it's set (and wrong) it
wont run the autodetect code and see your mistake, warn that "you did wrong
and will be dutifully ignored", and correct it? Why do you not set it?

Also, when the card IS found (say on 300) why does the code not try and use
the card (fake an ifconfig, kinda , or something... I dunno) and timeout
after 2 seconds, and if that test failed, just switch interupt to some likely
ones (5, 10, 11, 3 (obviouslu :\) ? Or maybe all IRQs?) and try again.
When found, change the kernels default value, and the user will have a
warning message saying he screwed up, but it's ok, it's been fixed for him.
(Ok... I seriously don't have a clue about the interupt handling, so this
may be complete garbage, but would someone tell me why, in a few words
more then "you can't"? :-)

Also there could be a little newbie helping thing that they could choose
instead of userconfig.

Something like:
-----

Answer the following questions by pressing the number for the
correct answer:

Do you have a network card?
  1. Yes.
  2. No.
  3. I don't know.

> 2

(Turn off all ISA network card probes)

Do you have a SCSI card?

...
or
...


Do you have a network card?
  1. Yes.
  2. No.
  3. I don't know.

> 1

What type of network card?
  1. Western digital, or clone  (NE1000 NE2000, etc)
  2. 3com                       (3c509, etc)
  ...
  6. PC-card one
  7. Don't know.

> 2

(Don't do probing of ed cards, etc)

----

Something like that might help us narrow down the search, and therefor
be able to set up what to probe and what not to probe for, in an easier
manner, and still maybe be able to go a little wilder on the probing, to
try and _find_ the right addresses and IRQs for the devices.

All this ofcourse, unless we can manage to probe for everything
automatically, at least with an option, so new users who can't get things to
work (which porbably run IDE anyway ;) can at least try and let the system
find everything by itself. If it's successful, great. If no, no big loss.
Think about it... Having a "This might hang your machine, but try it if not
all devices were found during your first try" choise would probably help
a lot of newbies get going. And if the SCSI will hang if we fiddle with it's
IRQs, etc, when probe for that kind of SCSI controller first, for heavens
sake, and just avoid the interupts you found that one on, if you did.
What's wrong with that? Try everything with non-intrusive probes first, and
avoid all known taken spots when going hay-wire with nasty probes.
Or I'm missing 93% of the picture... again. :-)

Comments? Preferably could someone explain how it's done today, what the 
problems are and what the future plans are. I've seen something about
changes in this area, but I'm really at a loss at what they are.

  /Mikael



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