In message <[EMAIL PROTECTED]> Joe Kelsey writes:
: Warner Losh writes:
: > In message <[EMAIL PROTECTED]> Joe Kelsey
: > : I also second Terry's comment about 0x800. There is no reason to add
: > : yet more driver flags in order to "do the right thing". The "do the
: > : right thing" case should always be default and a flag (sysctl variable,
: > : etc) should be used for those who want "the wrong thing".
: > The main reason that it wasn't added at the time was that it was
: > expensive in terms of CPU utilization, so it shouldn't be on by
: > default. There may be other reasons as well...
: Please explain the reference to "expensive in terms of CPU
: utilization". I have currently turned this code on by default (simply
: removed the if blocking and the hack comment) so that it always does the
: log message followed by the disable/enable calls. So far, where I used
: to see thousands of "out of sync" messages, I now have seen exactly one
: "out of sync" message followed by the "re-enable" message. I cannot see
: how a single disable/enable call at the first mouse motion can cause
: massive CPU utilization problems. But then again, maybe I am thinking
That's what I was told when I asked to make it default. The
enable/disable routines were, at least at the time, somewhat expensive
because they did things to the mouse port at 1uS per transaction and
there were lots of transactions.
: Please explain this. Do you expect to be resetting the mouse thousands
: of times per second? It is an error condition. The default must be to
: fix the errors. As soon as someone reports that the fix is being
: executed thousands of times per second on their broken hardware, then we
: can implement the opposite flag to disable the fix in those pathological
: cases where it causes a problem.
It is possible, i believe, to have patholigical cases where resetting
the mouse would cause another out of sync, which would cause another
reset, which would cause another out of sync, etc. This would result
in a hung system, for all intents and purposes. That's why it isn't
enabled by default. At least that's my dim recollection of the mail I
had with yokota-san, that may have been private.
: Again, all I am asking is for someone to explain why they make a design
: decision. The comment in the psm.c file about a "hack" is extremely
: unhelpful. Why did the coder think it was a "hack" solution? What were
: the pros and cons that went into that decision. Was there a discussion
: on -current about it that I missed? If there was a discussion and a
: conclusion was reached, the proper thing to do is to insert
: documentation into the code to explain the design decisions that were
: made. If you don't document the design in the code, it will be
: forgotton, as there is no other place to document it in FreeBSD.
Sometimes things don't get documented. That's the nature of the
A word about tone. If you were to get as in my face about, say,
pccard, as you about the psm driver, I'd certainly be ill inclined to
provide you with what you want.
Say Warner, why do you bother turning off the power after
you suspend a socket. Shouldn't the power routines take care
of that? Is there something subtle that's going on? Maybe a
comment is in order?
Please explain the pros and cons for turning the power off
after suspending a socket. I really want to know. Why did
they do this? Didn't the coder trust the power routines? The
least he could have done was include a comment. Was there
some long discussion that I missed?
See the difference? The first tone is friendly, suggesting that
something in the code might be unclear. The second seems to imply
that I'm a moron for not documenting every trivial solution with a 20
page thesis on why it is good or bad to do.
Also, sometimes you have to know when to give a point a rest.
Hammering this again so soon after yakota-san sent out his long, very
well written message that said he was going on a business trip and
would be out of touch isn't going to have the results you expected.
He'll get back from his trip and will likely be swamped. That's the
worst time to hit someone with a "hey, can you document this more"
P.S. The answer is that we don't power off before that point and if
we fail to power it off, the card will continue to draw power while
suspended and can cause machine hangs when the machine is resumed. A
careful tracing of the code shows that no power down commands are
issued in the disable path.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message