BUG in sermouse driver

BUG in sermouse driver

[Ondrej Zajicek]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

Hello

There is a bug in sermouse driver that inputattach program terminates
during suspend (or resume) to ram hence mouse does not work afer
resume. When i execute inputattach after resume, the mouse is
working.


strace from inputattach:

> ...
> select(4, [3], NULL, NULL, {0, 100000}) = 1 (in [3], left {0, 93000})
> read(3, "\t", 1)                        = 1
> select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
> ioctl(3, TIOCSETD, [2])                 = 0
> ioctl(3, SPIOCSTYPE or VTXIOCGETINFO, 0xbfb28c84) = 0
> read(3, NULL, 0)                        = 0
> ^^^^^^ here it is blocked before i start STR
> 
> ioctl(3, TIOCSETD, [0])                 = 0
> close(3)                                = 0
> exit_group(0)                           = ?


inputattach is just sleeping on last read(), which is not supposed
to return, but it returns during STR.


-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: BUG in sermouse driver

[Jiri Kosina]

On Mon, 10 Mar 2008, Ondrej Zajicek wrote:

> There is a bug in sermouse driver that inputattach program terminates 
> during suspend (or resume) to ram hence mouse does not work afer resume. 
> When i execute inputattach after resume, the mouse is working.

I know that Pavel (added to CC) knows where the problem is (improper fake 
signal handling around try_to_freeze() call), I guess he'd be able to 
provide a patch to test.

Thanks,

-- 
Jiri Kosina

Re: BUG in sermouse driver

[Pavel Machek]

Hi!

> > There is a bug in sermouse driver that inputattach program terminates 
> > during suspend (or resume) to ram hence mouse does not work afer resume. 
> > When i execute inputattach after resume, the mouse is working.
> 
> I know that Pavel (added to CC) knows where the problem is (improper fake 
> signal handling around try_to_freeze() call), I guess he'd be able to 
> provide a patch to test.

I don't have a patch ready, but I believe we localized the problem to
serport_ldisc_read().

        wait_event_interruptible(serport->wait,
+test_bit(SERPORT_DEAD,&serport->flags));

It does interruptible wait, but does not expect signals. We tried
something like:

do {
        wait_event_interruptible(serport->wait, test_bit(SERPORT_DEAD,&serport->flags));
} while (try_to_freeze());

...but that did not help IIRC.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: BUG in sermouse driver

[Dmitry Torokhov]

Hi,

On Mon, Mar 10, 2008 at 01:01:37PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > There is a bug in sermouse driver that inputattach program terminates 
> > > during suspend (or resume) to ram hence mouse does not work afer resume. 
> > > When i execute inputattach after resume, the mouse is working.
> > 
> > I know that Pavel (added to CC) knows where the problem is (improper fake 
> > signal handling around try_to_freeze() call), I guess he'd be able to 
> > provide a patch to test.
> 
> I don't have a patch ready, but I believe we localized the problem to
> serport_ldisc_read().
> 
>         wait_event_interruptible(serport->wait,
> +test_bit(SERPORT_DEAD,&serport->flags));
> 
> It does interruptible wait, but does not expect signals. We tried
> something like:
> 
> do {
>         wait_event_interruptible(serport->wait, test_bit(SERPORT_DEAD,&serport->flags));
> } while (try_to_freeze());
> 
> ...but that did not help IIRC.

I think the current behavior is correct one. The device 99% of the
time needs to be re-initialized after suspend to ram so returning
from read is sane thing to do, this allows us to singnal userspace
that device needs attention.

As far as userspace goes we could either try to get inputattach
reinitialize device or just make sure that inputattach is called
again from resume scripts.

-- 
Dmitry