I have gotten this system to boot with a current SMP kernel from as
late as mid-September 2000, and am working on stabilising the system
so that I can try later versions.
It seems that all the working versions don't use Ultra-160 (I'm not
sure when this hit the tree) - could the problem have been
>> That won't catch all interrupts. Most notably, you won't know
>> if commands are completing. Command completions are much more
>> prevalent than sequencer or scsi interrupts.
>
>should I try and catch the command completions? which routine is best
>to do this in?
ahc_intr() in aic7xxx_inlin
Justin T. Gibbs wrote:
> >John Baldwin wrote:
> >> Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try
> >> this: find the ahc driver's interrupt handler, and add a printf.
> >> Then see if the printf fires while the machine is hung.
> >
> >Ok, I put a printf in ahc_handle_seqint()
>John Baldwin wrote:
>> Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try
>> this: find the ahc driver's interrupt handler, and add a printf.
>> Then see if the printf fires while the machine is hung.
>
>Ok, I put a printf in ahc_handle_seqint() and ahc_handle_scsiint().
That wo
John Baldwin wrote:
> Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try
> this: find the ahc driver's interrupt handler, and add a printf.
> Then see if the printf fires while the machine is hung.
Ok, I put a printf in ahc_handle_seqint() and ahc_handle_scsiint().
My current (f
On 22-Jun-01 Dave Cornejo wrote:
> John Baldwin wrote:
>> Actuually, KTR is your friend here. :) Read the ktr(4) manpage, then
>> compile a
>> kernel with KTR_MASK and KTR_COMPILE set to KTR_INTR|KTR_PROC. Then when it
>> hangs, break into DDB and look at the longs via 'show ktr' to see if you
John Baldwin wrote:
> Actuually, KTR is your friend here. :) Read the ktr(4) manpage, then compile a
> kernel with KTR_MASK and KTR_COMPILE set to KTR_INTR|KTR_PROC. Then when it
> hangs, break into DDB and look at the longs via 'show ktr' to see if you can
> locate any interrutps coming in from
John Baldwin wrote:
> Ok, sounds good, just checking. :) Can you provide the output of mptable for
> this box? In the SMP case, -current does interrupt routing for PCI interrupts
> a bit differently, which might be a possible reason. Hmm, but you are getting
> interrupts eventually it seems.
I
On 21-Jun-01 Dave Cornejo wrote:
> John Baldwin wrote:
>> Is this on -current or -stable? If it's on -current, why did you ask on
>> -questions? :) It looks like an interrupt problem however.
>
> When I asked on questions, I was of the belief that I had a hardware
> problem and that it was not
John Baldwin wrote:
> Is this on -current or -stable? If it's on -current, why did you ask on
> -questions? :) It looks like an interrupt problem however.
When I asked on questions, I was of the belief that I had a hardware
problem and that it was not necessarily a -current issue. When I
later
On 17-Jun-01 Dave Cornejo wrote:
> Please excuse me if you've seen this in questions, but I found a
> relevancy to current: If I drop back to 4.3 release, this system boots
> every time with no hangs observed in half a dozen tries in either UP
> or SMP mode. Anyone else seeing similar?
Is this
>Please excuse me if you've seen this in questions, but I found a
>relevancy to current: If I drop back to 4.3 release, this system boots
>every time with no hangs observed in half a dozen tries in either UP
>or SMP mode. Anyone else seeing similar?
I doubt that this is related to CAM or the aic
12 matches
Mail list logo