From owner-freebsd-current Mon Jul 21 15:00:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA14479 for current-outgoing; Mon, 21 Jul 1997 15:00:01 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA14440 for ; Mon, 21 Jul 1997 14:59:56 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id AAA10525; Tue, 22 Jul 1997 00:02:40 +0200 (CEST) From: Mikael Karpberg Message-Id: <199707212202.AAA10525@ocean.campus.luth.se> Subject: Re: I am contemplating the following change... In-Reply-To: from Warner Losh at "Jul 21, 97 01:01:48 pm" To: imp@rover.village.org (Warner Losh) Date: Tue, 22 Jul 1997 00:02:40 +0200 (CEST) Cc: current@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk 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