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] [thread-next>] [day] [month] [year] [list]
Message-Id: <1254266783.2657.11.camel@localhost>
Date:	Wed, 30 Sep 2009 01:26:23 +0200
From:	Hermann Pitton <hermann-pitton@...or.de>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Paweł Sikora <pluto@...k.net>,
	linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
	LMML <linux-media@...r.kernel.org>
Subject: Re: [2.6.31] ir-kbd-i2c oops.

Hi Jean,

Am Dienstag, den 29.09.2009, 16:16 +0200 schrieb Jean Delvare:
> On Wed, 16 Sep 2009 10:03:32 +0200, Paweł Sikora wrote:
> > On Wednesday 16 September 2009 08:57:01 Jean Delvare wrote:
> > > Hi Pawel,
> > > 
> > > I think this would be fixed by the following patch:
> > > http://patchwork.kernel.org/patch/45707/
> > 
> > still oopses. this time i've attached full dmesg.
> 
> Any news on this? Do you have a refined list of kernels which have the
> bug and kernels which do not? Tried 2.6.32-rc1? Tried the v4l-dvb
> repository?
> 
> Anyone else seeing this bug?

I can see you ask the other way round, but just in case, I don't have
that bug neither on some self compiled 2.6.30 with recent mercurial
v4l-dvb on some outdated Fedora nor on a 

Linux localhost.localdomain 2.6.30.5-43.fc11.x86_64 #1 SMP Thu Aug 27
21:39:52 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

with my recently purchased older Pinnacle 310i.

Hm, there are different versions of that card, to have it mentioned,
obviously also with different remotes, and I can't tell how to identify
them.

> Your kernel stack trace doesn't look terribly reliable and I am not
> able to come to any conclusion. The crash is supposed to happen in
> ir_input_init(), but the stack trace doesn't lead there. I am also
> skeptical about the +0x64/0x1a52, ir_input_init() is a rather small
> function and I fail to see how it could be 6738 bytes in binary size.
> Might be that the bug caused a stack corruption. Building a debug
> kernel may help.

Cheers,
Hermann


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ