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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
