Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA639 ; Sat, 06 Feb 93 14:00:31 EST Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!yale.edu!yale!gumby!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!acs.ucalgary.ca!cpsc.ucalgary.ca!xenlink!newt.cuc.ab.ca!deraadt From: deraadt@newt.cuc.ab.ca (Theo de Raadt) Subject: Re: [386BSD] Followup: WD8013 card In-Reply-To: terry@cs.weber.edu's message of Tue, 26 Jan 93 20: 55:04 GMT Message-ID: <DERAADT.93Feb1010127@newt.newt.cuc.ab.ca> Sender: news@newt.cuc.ab.ca Nntp-Posting-Host: newt.fsa.ca Organization: little lizard city References: <C1FuJ7.4A9@rot.qc.ca> <1993Jan26.205504.24467@fcom.cc.utah.edu> Date: Mon, 1 Feb 1993 08:01:27 GMT Lines: 54 In article <1993Jan26.205504.24467@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: In article <C1FuJ7.4A9@rot.qc.ca> captain@rot.qc.ca (Andrew Webster) writes: >The WD8013 does seem to exhibit odd behaviour as the kernel only detects >the card from a cold boot / power up. >One person who responded mentioned this problem. It is wide spread? >Is there a fix? The problem is that a warm boot does not cause a card reset. This is arguably a defect in the card. The probe routine could be modified to forcibly reset the card; however, if this is done, what is the point of having a probe routine (since you must assume the card is present to reset it)? Hmm. I guess the BSD guys must have been on too many drugs then when they wrote a large number of the device drivers to do exactly this. I always thought it was perfectly normal behaviour for a probe routine to 1) assume the device is there 2) reset it 3) cause an interrupt 4) if you get the interrupt, you win! 5) if you timeout waiting, device is not present, return failure. Now, the 386BSD code as it stands does not do much of this. In fact, it generally keeps interrupts off. I'm not a fan of this at all. If we were to write the probe routines more carefully, we could do this: controller wdc0 at isa? port "IO_WD1" bio irq ? vector wdintr controller fdc0 at isa? port "IO_FD1" bio irq ? drq 2 vector fdintr controller wds0 at isa? port "IO_WDS" bio irq ? drq 6 vector wdsintr controller ahb0 at isa? port "IO_AHB0" bio irq ? drq ? vector ahbintr device npx0 at isa? port "IO_NPX" irq ? vector npxintr device com0 at isa? port "IO_COM1" tty irq ? vector comintr device com1 at isa? port "IO_COM2" tty irq ? vector comintr device we0 at isa? port 0x280 net irq ? iomem 0xd0000 iosiz 8192 vector weintr Note how all the irq lines don't specify an irq? Why, just go out and probe the sucker! You can cause a fake interrupt with ALL of the above devices if I am not mistaken. If this method is used, we don't have to worry about getting all those nasty little interrupt vectors correct any longer, and trying to watch out for errors. The isa_configure() routine can watch for conflicts, since it is the routine that calls each of the probe routines. Notice how the ahb controller does not have a drq line either? Some controllers can tell you what DRQ they are configured to use.. Every day I spent in 386BSD, I am amazed at how much stuff got lost in the transition from BSD4.3tahoe to BSD4.3reno to NET2 to 386BSD... <tdr. -- This space not left unintentionally unblank. deraadt@newt.cuc.ab.ca