Hello,

> So the uni-north on the first AGP G4 and later are OpenPIC? The B&W G3 
> is Grackle/Heathrow with a CMD IDE chip for the internal HD, and I'm 
> pretty sure it's the same for the PCI graphics G4.
Apparently. 

> >> umass0: BBB reset failed, TIMEOUT
> >> umass0: BBB bulk-in clear stall failed, TIMEOUT
> >> umass0: BBB bulk-out clear stall failed, TIMEOUT
> >> umass0: BBB reset failed, TIMEOUT
> >
> > I suspect at least some of this could be missed interrupts.
> 
> I tried copying off my firewire burner and the data light just goes on 
> and then off for like 5 seconds, then it picks up again and starts 
> copying for about 10 seconds and stops again. Now it's stopped 
> completely. cp is waiting on uvn_fp2 and the fwohci0 thread is waiting 
> on fwohciev.
Please look at systat 1 vmstat when making experiments like that and see if IRQs stop firing ( for a couple of seconds ) and start again or if they stop completely for any particular IRQ. I /think/ deadlocks related to the interrupt handler ( which would lead to some IRQ(s) stop getting any attention ) shouldn't happen anymore and sure enough I didn't see any since Allen committed the changes to extintr.c but my machine seems to be weird anyway :)

> I dunno if the USB code just left the system in a weird state or what. 
> After the reboot I tried to copy the file down again and it started out 
> at 1MB/sec then dropped slower and slower and slower, now it's down to 
> 40 KB/sec and dropping. Very strange.
Indeed. So it didn't lock up completely ( as it did for me before the patch ), definitely looks like lost interrupts ( or extremely high latency ) - apparently there's something fishy in the handler, it sometimes seems to gets stuck in a high priority level or so - I wonder why all these problems avoid me so I can't properly track them down :/
Hmm, bm seems to be the only device that uses interrupts from the 2nd controller, somehow I'd have expected that these make problems and the lower 32 work fine

have fun
Michael