Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx

2007-03-17 Thread Grant Grundler
On Thu, Mar 15, 2007 at 11:25:10AM -0400, Jeff Garzik wrote: ... > Here's the problem with this: this printk is signalling that the DMA > engines have not yet stopped, which is an event of which we should be wary. > > While it makes sense to do this patch, since the complaining cards > appear t

Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx

2007-03-15 Thread Valerie Henson
On Thu, Mar 15, 2007 at 11:25:10AM -0400, Jeff Garzik wrote: > > Here's the problem with this: this printk is signalling that the DMA > engines have not yet stopped, which is an event of which we should be wary. > > While it makes sense to do this patch, since the complaining cards > appear to

Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx

2007-03-15 Thread Jeff Garzik
Valerie Henson wrote: Only print out debugging info for tulip_stop_rxtx if debug is on. Many cards (including at least two of my own) fail to stop properly during initialization according to this test with no apparent ill effects. Worse, it tends to spam logs when the driver doesn't work. Signe

[patch 4/6] [TULIP] Quiet down tulip_stop_rxtx

2007-03-12 Thread Valerie Henson
Only print out debugging info for tulip_stop_rxtx if debug is on. Many cards (including at least two of my own) fail to stop properly during initialization according to this test with no apparent ill effects. Worse, it tends to spam logs when the driver doesn't work. Signed-off-by: Val Henson <[E