![]() | |||||||||||||
Messages in this thread |
Rusty Russell wrote: > In message <3D8FD0A9.1010906@pobox.com> you write: > >>>@@ -325,7 +326,8 @@ >>> while(inb(cmd_ioaddr) && --wait >= 0); >>> #ifndef final_version >>> if (wait < 0) >>>- printk(KERN_ALERT "eepro100: wait_for_cmd_done timeout!\n"); >>>+ problem(LOG_ALERT, "eepro100: wait_for_cmd_done timeout!", >>>+ detail(ioaddr, "%lx", cmd_ioaddr)); >> >>bloat, the ioaddr can easily be deduced > > > No! That's *exactly* the problem: you see: > eepro100: wait_for_cmd_done timeout! > > in your logs, now *which* of the 5 eepro100 cards was it? > > wait_for_cmd_done(long cmd_ioaddr) should take a 'struct net_device *' > and use net_problem, then no details needed. right, that's a bug, it needs struct net_device * like the standard Becker style. >>>- printk (KERN_ERR "eepro100: cannot reserve MMIO region\n"); >>>+ pci_problem(LOG_ERR, pdev, "eepro100: cannot reserve MMIO regio >> > n"); > >>bloat, no advantage over printk > > > Now, which of those 5 cards was it again? Another bug, this driver should be using pci_request_regions() which prints that stuff out :) Does IBM want to submit a patch that cleans up these problems, and makes the existing event logging more standard [and is compatible with existing 2.4 and 2.5 kernels]? As an aside, changing all those printks also introduces a _huge_ PITA for driver developers porting drivers back and forth between 2.4 and 2.5. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 12:29 [W:0.198 / U:0.030 seconds] ©2003-2008 Jasper Spaans | |||||||||||||