Re: kernel-image-2.6.7
On Thu, 2004-08-12 at 14:13, Dana Sibera wrote:
> > I can't really help you with the SCSI messages yet, but I see something
> > else:
> >
> > Unexpected IRQ 3 on device 00000000
> >
> Certainly - though the same Unexpected IRQ 3 comes up throughout the
> boot with the earlier working kernels, until klogd starts up. I had
> this appearing for a while and couldn't find answers on what it was
> for, and it didn't seem to cause harm, so I changed kernel logging
> options in /etc/init.d/klogd to KLOGD="-2 -c 4", which hid the
> messages. The Quadra 605 ran as a webserver for a year, rock solidly.
Hmm, sounds fishy to me. Lovely undocumented hardware...
Maybe you found the DMA interrupt for the SCSI! ;-)
Looks like the Mac-specific NCR53C9x driver only works in PIO mode...
> Here are the interrupts as they appear under the working kernel
> (2.2.19, not 2.2.20 as I wrote before).
>
> $ cat /proc/interrupts
> auto 0: 0 spurious int
> auto 1: 47552 L VIA1 Dispatch
> auto 2: 8236 L VIA2 Dispatch
> auto 3: 54 int3 handler
> auto 4: 0 L SCC Dispatch
> auto 5: 0 int5 handler
> auto 6: 0 int6 handler
> auto 7: 0 L NMI
> via1 9: 19150 console/cursor
> via1 10: 1622 adb CUDA interrupt
> via1 14: 29947 timer
> via2 17: 47703 F Nubus Dispatch
> via2 19: 8085 Mac ESP SCSI
> scc 33: 0 SCC A
> scc 34: 0 SCC B
> nbus 61: 151 sonic
I see it has SCC serial ports. Do they work under 2.6? If so, do you
have the posibility to do serial debugging? I could try and help you
with the SCSI issue then, by building a debugging version, but you
really want to be able to log its output...
When I look at the current info from your screenshot, it seems the chip
"misses" an interrupt. The last SCSI phase was MSG IN, and the driver
phase is freeing, which is when the driver is waiting for the disconnect
(bus free) interrupt. Apparently that didn't arrive, and the command
timed out. In the abort routine the hardware is re-read, showing a
disconnected state!
It seems the abort routine at least has a bug since it's still trying to
abort a disconnected command, causing the invalid command interrupt.
Of course, this might all be caused by a long stream of SCSI bus resets
preceding your "screen shot".
If you want this fixed I think you really need a serial console, unless
the Mac has some other means of saving the kernel messages (like the
Amiga in a portion of RAM).
Kind regards,
Kars.
Reply to: