On Fri, 5 Jan 2007, Michael Schmitz wrote:
Maybe the message can be disabled, if just a few packets in the
transmit ring is normal for macmace :-)
Yes, that's normal, but the same tx_count variable that triggers the
"ran out" message when 0 also trips the netif_wake_queue when
non-zero, which
You mean netif_wake_queue gets run already when there are still packets
to be sent? How would that explain the timeout?
I just meant that perhaps tx_count can't always be depended upon for the
number of empty buffers. That could explain both the tx timeout and the
"ran out" message. I guess it is equally possible that tx_count is
accurate and buffers just aren't being transmitted by the NIC.
The bad news is my Daystar Mac II and LC630 no longer boot (they were
ok around 2.6.10). My Mac IIci doesn't boot either, but that never did
boot 2.6. The Q650 and Q700 are usually OK, but the 650 sometimes
fails with the same SCSI failure that kills the 630 on almost every
boot (but even 2.6.7 had that bug, just harder to trigger. It only
fails during device probing. If you get past that, it is solid.).
Some stray interrupt coming in while SCSI is probing, and messing up
things in the interrupt handler? Does it hang with interrupts disabled?
No idea what changed since 2.6.10 ... the IIci perhaps fails due to
screen memory getting in the way in the low memory bank. While I think
about it - one major change was the discontiguous memory support. But
that usually improved things.
I'm going to have to look into this more closely. With my kernels I get a
different result to Christian's kernel on the IIsi. Don't know yet whether
the IIci or ESP SCSI problems go away with Christian's kernel.
This could be caused by some of the patches I'm using, or my .config or
just because I'm using 2.6.19 not 2.6.18. But mac_scsi seems to be broken
either way (I know it worked around 2.6.10). Looks like I'm going to need
an NFS root filesystem to test Mac II ADB on the older machines.
-f
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
