Jeff Garzik wrote:
Rick Jones wrote:
But that is rather incidental isn't it? Would some sort of system
health monitor be likely to be checking that for interrupt flavors? And
Well, that's where the information is exported in a standard way. I
hope you're not suggesting that a system health monitor should be
parsing random, driver-specific printk messages to obtain the same
information?
No, I wouldn't. The only "system health monitor" I would expect to be parsing
that sort of thing would be a human. Perhaps I'm just backing-into the meta
question via the specifics of this driver patch.
just looking at /proc/interrupts, while it tells you what sort of
interrupt is being used, it doesn't (IIRC) say anything about what
sort of interrupt the driver _tried_ to use.
True.
In the context of this thread, it could be any number of reasons: MSI
isn't compiled in. MSI was disabled at runtime via kernel command line.
MSI was disabled by BIOS quirk. MSI enable was attempted, but failed
for some reason.
None of those reasons are really driver-specific, or need
driver-specific complaint messages.
Agreed. But is the PCI (?) subsystem doing something in that regard or is this
a hole?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
