From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 8 Sep 1995 14:43:46 -0400 From: jmk@plan9.att.com jmk@plan9.att.com Subject: panic: ataintr: wait busy Topicbox-Message-UUID: 22465602-eac8-11e9-9e20-41e7f4b1d025 Message-ID: <19950908184346.U5MpKeKiCEuVvQV0VwmG6leBv9I2cbmvO5qypt66CBM@z> Close... The distributed trap.c already has code for this: if(v >= Int0vec && v < Int0vec+16){ /* an unknown interrupt */ v -= Int0vec; /* * Check for a default IRQ7. This can happen when * the IRQ input goes away before the acknowledge. * In this case, a 'default IRQ7' is generated, but * the corresponding bit in the ISR isn't set. * In fact, just ignore all such interrupts. */ if((isr & (1<pc, badintr[v]); print("isr = 0x%4.4ux\n", isr); } } else { and devata.c does not set IRQ15, it only handles one ATA controller at present. It's more likely either the BIOS needs to have the ATA controller disabled and/or all drives marked as 'none', or, if there is an ATA drive connected, the Adaptec shouldn't be using IRQ14. I usually set the first SCSI controller on IRQ11 and the first ethernet controller on IRQ10. --jim ------ original message follows ------ >>From cse.psu.edu!9fans-outgoing-owner Fri Sep 8 14:37:03 EDT 1995 Received: by colossus.cse.psu.edu id <45706>; Fri, 8 Sep 1995 14:07:15 -0400 Received: from westlake.tkg.com ([198.3.130.68]) by colossus.cse.psu.edu with SMTP id <45727>; Fri, 8 Sep 1995 13:53:10 -0400 Received: from kernel.austin.ibm.com (kernel.austin.ibm.com [9.3.22.57]) by westlake.tkg.com (8.6.12/8.6.10) with SMTP id MAA03231 for <9fans@cse.psu.edu>; Fri, 8 Sep 1995 12:42:27 -0500 Received: by kernel.austin.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA33892; Fri, 8 Sep 1995 12:42:09 -0500 Date: Fri, 8 Sep 1995 13:42:09 -0400 From: daveb@tkg.com (Dave Burton) Message-Id: <9509081742.AA33892@kernel.austin.ibm.com> To: 9fans@cse.psu.edu Subject: Re: panic: ataintr: wait busy Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu | The machine I can use for plan9 was finally delivered. It's a 486 with an | Adaptec 1542 of some flavor. When I boot I get wait busy panics. I updated | my disks this afternoon and when I copy b.com and 9dos to C: and do | | C:\b sd!0 | | It sees both of the disks I have installed, but after 9dos boots I get this: | | 5569 free pages, 22276K bytes, swap 11126K, highwater 1112K, headroom 1388K | CPU is a 33 MHz Intel486DX (cpuid: ax 400 dx 0) | scsi0: aha1542: port 330 irq 14 dma5 | panic: wait busy cmd=0 status=ff | | Anyone seen this one before? A search for adaptec and ataintr in my 9fans | archive didn't help much. I haven't made the fix for this yet, but can describe the problem, or at least one similar. I have a machine with an Adaptec 1542CF and no IDE. Every so often, I get a ``panic: ataintr: wait busy.'' This is due to a bogus irq 15, which is directed to the ata driver in the distributed 9pc kernel. The problem is related to that of the rogue irq 7's, which is tied to the implementation of interrupt detection on PC MB's. Basically, random noise spikes can induce a false interrupt on either irq 7 *or* irq 15, depending upon which 8259 detects the noise. + trap.c (sorry, I don't have the source code in front of me) has rogue irq detection and toss logic, but only for unregistered irqs. Since irq 15 is populated with the ata (IDE) driver, this means that rogue interrupts on irq 15 will hit the ata driver and cause a panic if there is no adapter to get status from. I think the default line printer driver goes to irq 7, but its interrupt routine simply does a wakeup, which doesn't cause any problems. I think the correct fix is to check for rogue interrupts in trap.c *before* dispatching to any registered interrupt handlers. This would involve moving the rogue interrupt logic to proceed the registration checks in trap.c. Of course, removing extraneous drivers will help, too. :-) I was waiting to post this until I could implement and test the fix, but I haven't had much spare time recently. Hopefully, I will get to this this weekend, and I'll post a tentative patch once I've tested it. BTW, kudos on both ACME and the general organization of the source code externally and internally. It is pleasant to work with such ``clean'' code. ACME allowed me to quickly understand much of the internal workings of plan9, and the sources did not obfuscate their intent. -- Dave + See MindShare, Inc's excellent book _ISA System Architecture_. ISBN: 1-881609-05-7.