Daniel Exner wrote:
> Jiri Kosina wrote:
>> On Fri, 10 Aug 2007, Daniel Exner wrote:
>>> Please CC me, as I'm currently not subscribed to this list, thx.
>>
>> Please also don't forget to CC relevant people/lists when reporting
>> bugs, thanks.
> Guess its ok, now? Thanks anyway :)
>
>>> After some serious hangs with 2.6.23-rc2 I did some bisects and
>>> this was the result: 196705c9bbc03540429b0f7cf9ee35c2f928a534 is
>>> first bad commit commit 196705c9bbc03540429b0f7cf9ee35c2f928a534
>>> Author: [email protected] <[email protected]>
>>> Date: Thu May 3 08:58:49 2007 -0700
>>
>> I guess that the patch attached to bug 8535 in kernel.org bugzilla --
>> http://bugzilla.kernel.org/attachment.cgi?id=12228&action=view --
>> solves your issues, right?
> Nope, this does _not_ fix my issue.
>
> Anything else I could try, or some files you need?
> I tried finding some clue in my logs, but without any results so far.
>
> Greetings
> Daniel Exner
It appears that the VIA controllers just ignore the "inactivate" bit
completely.
Normally, when I set the "inactivate" bit in the QH and then watch the
QH & overlay, I eventually see the controller clear the "active" bit in
the overlay token, and, of course, it doesn't do the transaction.
With the VIA controller I have, after I set the "inactivate" bit, I
eventually see the controller set bit 1 in the overlay token
(SplitXstate), indicating that it's running the transaction, and, a
couple microframes later, it clears that bit again. The transaction is
not inactivated.
The problem occurs if a transaction completes when the "inactivate" bit
is set... qh_completions will ignore the transaction until the
"inactivate" bit is cleared, and then, when the transaction should be
re-activated, my patch will set the "active" bit back to 1 in the
overlay & qtd token, even though the transaction was already completed
by the controller...
To work around this, I'd have to re-write my patch so that it didn't
depend on the "inactivate" bit at all... I suppose it could possibly be
done just by directly manipulating the "active" bit in the overlay
token, since already the code doesn't mess with the overlay if there's
any chance that the transaction is alrady cached or in progress, but
that would be tricky.
Perhaps for now the best thing would just be to bypass the EHCI CPU
frequency notifier code (i.e., my patch) for VIA EHCI controllers, since
they are broken. Would a hard-coded blacklist (just an "if
(manufacturer==VIA)..." type thing) be OK?
I've also acquired a card with an NEC EHCI controller on it, which I'm
going to look at while I'm into it...
Thanks
Stuart
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
