Re: Still Deadlock problem with pbbuttonsd 0.6.10?

[Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de>]

> > > the trackpad programming sequence initiated from user space is not
> > > atomic.
> >
> > Neither is programming the PMU via pmud-utils' trackpad tool.
>
> Yes, I know. I got my code from the trackpad tool :-)

Guessed as much :-)

> > Do you do anything different WRT PMU monitoring when on AC? Maybe it's a
> > race between trackpad programming and power monitoring. I'll try running
> > your 0.6.10 in pmud compat mode sometime to check that.
>
> I do nothing special. Pbbuttonsd program the trackpad in one sequence:
> Prg mod on, change trackpad mode, Prg mode off. There is no difference

And that's once only, not each time the user has been typing then stopped?

> between battery or AC I know off. Pbbuttonsd read the battery status through
> /proc/pmu instead of asking the PMU directly, so I don't see any relationship
> here.

That should not be a problem - the PMU driver only queries for battery
state on timer or environment interrupts. On my machine, on AC no timer
interrupts happen - see /proc/pmu/interrupts for this, maybe the
'problematic' machines are using a different interrupt?

How many PMU interrupts in a row do these machines ever see? I'm thinking
of a race between PMU commands and other ADB interrupts here, though I'm
not sure this can happen. If the kernel totally hangs (including
communication with the PMU), the PMU will shut down the machine after a
while.

In no way there should be a problem with user space reading /proc/pmu/.

	Michael