|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Fri, 6 Feb 1998 22:44:41 +0100 (MET) From: Jerko Golubovic <jgolubov@public.srce.hr> To: Jay Vassos-Libove <libove@felines.org> cc: linux-scsi@vger.rutgers.edu In-Reply-To: <Pine.LNX.3.96.980206074722.664A-100000@panther.felines.org> On Fri, 6 Feb 1998, Jay Vassos-Libove wrote: > Okay, I've lost an IRQ line. I changed the IRQ setting on the AHA1542CF > to 9, and it works. Clearly, IRQ 11 is dead for some reason. It isn't > due to a device conflict -- there were no other devices in the bus which > could conflict. (Just the AHA1542 and a PCI video board). The BIOS has > no IRQ assignment functionality. (This is an old P133 Micron board). I wouldn't be so sure for that anyway.... What my experience tells me (and I had QUITE of it due to Bill's Ideas of PnP and how PnP is supposed to work) that IRQ11 is used by PCI card. Well, whatever it is configured, some boards behave quite idiotic when resource allocation is in game and usually it's case that PnP rules-out what you set-up and you cannot do very much about. Second thing to consider is burned IRQ line in IRQ controller (changing CPU as you suggested won't help at all) - I have such board where IRQ15 was burned when cheap VLB card died (I wired second IDE on IRQ11, Linux allowed me to do so). On today's boards you have chips with high levels of integration and such chips usually have weak buffer drivers - what normal Intel 8259 PIC can stand/drive, today's chip cannot - it will fail or burn. Driving self-powered radio-modem from onboard port (as an example to describe situation) won't work - if you have Motorola 1488/1489 (standard RS232 drivers) modem will work OK - they can deliver sufficient current to power single-IC BELL103/202 modem. And I saw some onboard serial ports which driver circuits were burned (yes, burned) when mouse cable got short-circuited. We radio-amateurs and electronic hobbysts prefer to use cards with replacable driver circuits so that we don't have to dump mainboard in case of lightning, voltages above 20, which will not burn when shorted and so.... So, that I get back on IRQ lines stuff. In IDE documentation is mentioned that you can share same IRQ for two IDE ports, but there is also an fat warning that line may burn because buffer drivers may not stand two devices connected in parallel - they are not designed in that way. So, if ever happened that control logic on your board assigned some other card/slot IRQ in parallel to 1542 it may happen that M/B line or even 1542 line 11 burns (I have 1542 - IRQ's are configured in software way - from BIOS, so there is separate output buffer driver on each possible IRQ which you cazn theoretically burn) which is quite unpleasant situation you have to deal with. Try to test card in different PC to confirm this option. And especially if you run Win95 on same machine this can happen - Win95 does *quite* nasty things every time you start machine and belive me - doesn't know how to isolate IRQ used by 1542 by querying 1542 BIOS (as Linux does, and fact is that Windows95 doesn't know, as far as I know, anything about 1542) neither knows any kind of resource locking in the way Linux does it on boot - in short words: "everything is floating and flexible all the time, and when you test, test everything with everything and in that way you will be compatible with all upcoming shit"... oops that's no good then Microsoft said and then "from 1999 no computer should have ISA bus if it wants to qualify for Windows Compatible". So much about - when you compare those two sentences. Fact is that most of people around doesn't know what PnP in W95 is doing in background and what kind of damage it can do.... I had one 3C509B Etherlink III COMBO network card (you cannot say that 3C509B is bullshit - it costs very much and has >10 years factory warranty) which was screwed-up by W95 - in fact EEPROM data was screwed-up by PnP procedures in such way that factory provided setup program was not able to correct situation (total EEPROM reset done by 3c5x9.c from Linux brought card back to life) - so much about what can happen during such "PnP". > Thanks for all of the suggestions from everyone -- unfortunately, it > really has turned out to be a hardware failure. Well, I tried here (as somebody skilled in electronics buisness) to explain what's going on behind, what's going on in industry strategies and what are possible pitfalls that you as user should be informed about. I hope that informations provided here were useful to somebody. > A last question that comes to mind: At this point, what would you do? > Use the board and avoid IRQ 11? Replace it? (I'm assuming here that the > motherboard, not the CPU, failed. If the CPU is going bad, I want to dump > it before it corrupts data). CPU has nothing to do (on PC) with IRQ lines. IRQ lines are PIC (Programmable Interrupt Controller) task. Test motherboard and card. /\/\
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |