Alan Cox wrote:
That does imply some muppet 'extended' the debug interface for power
management on your laptop. Also pretty much proves that for such systems
we do have to move from port 0x80 to another delay approach.
Alan - in googling around the net yesterday looking for SuperIO chipsets
that claim to support port 80, I have found that "blade" servers from
companies like IBM and HP *claim* to have a system for monitoring port
80 diagnostic codes and sending them to the "drawer" management
processor through a management backplane. This is a little puzzling,
because you'd think they would have noticed port 80 issues, since they
run Linux in their systems. Maybe not hangs, but it seems unhelpful to
have a lot of noise spewing over a bus that is supposed to provide
"management" diagnostics. Anyway, what I did not find was whether there
was a particular chipset that provided that port 80 feature on those
machines. However, if it's a common "cell" in a design, it may have
leaked into the notebook market chipsets too.
Anyone know if the Linux kernels used on blade servers have been patched
to not do the port 80 things? I don't think this would break anything
there, but it might have been a helpful patch for their purposes. I
don't do blades personally or at work (I focus on mobile devices these
days, and my personal servers are discrete), so I have no knowledge.
It could be that the blade servers have BIOSes that don't do POST codes
over port 80, but send them directly to the "drawer" management bus, of
course.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
