linux-kernel - Re: 2.6.26-rc3 - appletouch resume "incomplete data package"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 30 May 2008 10:41:43 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Bob Copeland <me@...copeland.com>
Cc:	oliver@...kum.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org
Subject: Re: 2.6.26-rc3 - appletouch resume "incomplete data package"

On Thu, 2008-05-29 at 22:56 -0400, Bob Copeland wrote:
> On Mon, May 26, 2008 at 7:06 AM, Johannes Berg
> <johannes@...solutions.net> wrote:
> > On Sun, 2008-05-25 at 16:24 -0400, Bob Copeland wrote:
> >> This appears to be a regression since 2.6.25.  After resuming, I get:
> >>
> >>     appletouch: incomplete data package (first byte: 2, length: 4).
> >>     appletouch: incomplete data package (first byte: 2, length: 4).
> >>     appletouch: incomplete data package (first byte: 2, length: 4).
> 
> > I have intermittently seen this problem happen for quite a while, a
> > bisect will probably not help you.
> 
> Hmm, well the console switch in suspend may be triggering it, but I
> didn't have the issue in 2.6.25 and it seems to be easily repeatable
> for me in .26 so far.  Doing ctrl-alt-f1 to switch to text mode and
> back a dozen times didn't break the mouse, but suspending once did.

Oh I didn't say it breaks, the thing is I get this message once a while
without it breaking, while suspend once a while breaks it (but I'm not
sure the message happens when it breaks)

> I tried a bisect anyway but didn't come up with any smoking gun.  Darn.

Yeah, I tried looking at the code but didn't really find anything
either. There must be something else... The thing is, nothing makes
sense unless there's a bug elsewhere, because it works fine after you
resume broken and reload the module. But reloading the module doesn't
really do anything to the hardware, it only submits a new urb while
resume simply resubmits the old one. All the other code is
kernel-internal housekeeping stuff.

Or can the urb endpoint information change so we need to re-do
usb_fill_int_urb?

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)