FS#15270 - [kernel26] 2.6.30 "kernel panic" with a number of usb devices.

Attached to Project: Arch Linux
Opened by Alexander Kaltsas (firewalker) - Friday, 26 June 2009, 12:53 GMT
Last edited by Andrea Scarpino (BaSh) - Monday, 05 October 2009, 16:39 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture i686
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:

My problem:

When using rt73usb driver for my wireless usb rt73 based card the system
crashes. This doesn't happen immediately after the module is loaded. It happens
when the software tries to bind the card with a wireless network (retrieve i.p.
for the card via dhcp e.t.c.).

There is another weird thing going on with the usb. If I start my system with
my usb mouse (15d9:0a33) there will be a kernel panic when trying to move the
mouse. Removing the mouse (no mouse plugged in, or only one ps2 mouse) doesn't
solve the problem. The system will crash when asking for an i.p. from the
router. If I plug another mouse I have (046d:c51a) the system doesn't kernel
panic. Removing my rt73 based wireless card or disabling the network tools that
uses this card solves the problem. I can't fully understand if this is an issue
that concerns only the rt73usb driver or is a generic issue for the usb kernel
driver.

The system doesn't alway kernel panic. Some time it produces an Oops message
and will panic some time later. Usually when trying to start X.


Steps to reproduce:

Try to boot a system using rt73usb without any pointing device or with the
15d9:0a33 mouse.


General:

See the following thread for more info.

http://bbs.archlinux.org/viewtopic.php?id=74622

Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:

Try to boot a system using rt73usb without any usb pointing device or with the
15d9:0a33 mouse.



Additional infos:
   Oops_Message (2 KiB)
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Monday, 05 October 2009, 16:39 GMT
Reason for closing:  Upstream
Additional comments about closing:  Upstream. Please report to upstream if not already solved/reported.
Comment by Alexander Kaltsas (firewalker) - Monday, 29 June 2009, 11:53 GMT
Is there any suggestion on what is causing those errors with usb devices? Is it an upstream bug?
Comment by Alexander Kaltsas (firewalker) - Saturday, 04 July 2009, 11:15 GMT
Is there any way to use git kernel bisection method with makepkg for the arch kernel?

http://bugzilla.kernel.org/show_bug.cgi?id=13681
Comment by felix (xilef) - Monday, 06 July 2009, 03:16 GMT
I have a feeling it could be more related to the rt2x00 series of modules. I have a network card that uses the rt61 module which itself depends on the rt2x00 as does the rt73 (I believe). I get random kernel panics at boot and my network card does not register.
Comment by Alexander Kaltsas (firewalker) - Tuesday, 14 July 2009, 14:58 GMT
Ok... I finished bisecting the kernel. I think that the error has to do
something with memory management (mm). git say:

32b154c0b0bae2879bf4e549d861caf1759a3546 is first bad commit
commit 32b154c0b0bae2879bf4e549d861caf1759a3546
Author: Mel Gorman <mel@csn.ul.ie>
Date: Thu May 28 14:34:37 2009 -0700


Here is the git entire bisect log.



GOOD
Bisecting: 6508 revisions left to test after this (roughly 13 steps)
[3c6fae67d026d57f64eb3da9c0d0e76983e39ae3] Merge branch 'hwmon-for-linus' of
git://jdelvare.pck.nerim.net/jdelvare-2.6


GOOD
Bisecting: 3273 revisions left to test after this (roughly 12 steps)
[22ae77bc7ac115b9d518d5cbc13d39317079b2b0] Merge
git://git.infradead.org/mtd-2.6


GOOD
Bisecting: 1612 revisions left to test after this (roughly 11 steps)
[418df63c2d94f238ac7e1d1d53be35dd6b7a7252] Delete slow-work timers properly


GOOD
Bisecting: 806 revisions left to test after this (roughly 10 steps)
[60befb97f5ab11037f1ae7563ca7137878a7bd46] Merge branch 'fix/asoc' into
for-linus


GOOD
Bisecting: 413 revisions left to test after this (roughly 9 steps)
[6c2445efb816a34dab7bb7357317e2d656f14cb1] Merge branch 'for-linus' of
git://git.kernel.dk/linux-2.6-block


BAD
Bisecting: 207 revisions left to test after this (roughly 8 steps)
[3da9e9d34ed7d2f5c33fd194d9dd09e15f4e51c0] Merge branch 'drm-intel-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel


GOOD
Bisecting: 102 revisions left to test after this (roughly 7 steps)
[60a0cd528d761c50d3a0a49e8fbaf6a87e64254a] Merge branch 'merge' of
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc


GOOD
Bisecting: 51 revisions left to test after this (roughly 6 steps)
[ebd4c994d2f917dffec882e7a77c28c6b28758ac] Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel

GOOD
Bisecting: 25 revisions left to test after this (roughly 5 steps)
[bd6daba909d8484bd2ccf6017db4028d7a420927] procfs: make errno values consistent
when open pident vs exit(2) race occurs


BAD
Bisecting: 12 revisions left to test after this (roughly 4 steps)
[715fe7af9fd7328af661742bfadc195e665a837f] edac: AMD8111 & AMD8131 Kconfig
fixup


GOOD
Bisecting: 6 revisions left to test after this (roughly 3 steps)
[8e8e8267f0a08c2415d5f51bc9a9fde6d5400619] serial: 8250_gsc: fix printk format
error


BAD
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[32b154c0b0bae2879bf4e549d861caf1759a3546] x86: ignore VM_LOCKED when
determining if hugetlb-backed page tables can be shared or not

GOOD
Bisecting: 1 revisions left to test after this (roughly 1 steps)
[53b7479bbdaedcc7846c66fd608fe66f1b5aa35b] atmel_lcdfb: correct fifo size for
some products





32b154c0b0bae2879bf4e549d861caf1759a3546 is first bad commit
commit 32b154c0b0bae2879bf4e549d861caf1759a3546
Author: Mel Gorman <mel@csn.ul.ie>
Date: Thu May 28 14:34:37 2009 -0700

x86: ignore VM_LOCKED when determining if hugetlb-backed page tables can be
shared or not

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13302

On x86 and x86-64, it is possible that page tables are shared beween
shared mappings backed by hugetlbfs. As part of this,
page_table_shareable() checks a pair of vma->vm_flags and they must match
if they are to be shared. All VMA flags are taken into account, including
VM_LOCKED.

The problem is that VM_LOCKED is cleared on fork(). When a process with a
shared memory segment forks() to exec() a helper, there will be shared
VMAs with different flags. The impact is that the shared segment is
sometimes considered shareable and other times not, depending on what
process is checking.

What happens is that the segment page tables are being shared but the
count is inaccurate depending on the ordering of events. As the page
tables are freed with put_page(), bad pmd's are found when some of the
children exit. The hugepage counters also get corrupted and the Total and
Free count will no longer match even when all the hugepage-backed regions
are freed. This requires a reboot of the machine to "fix".

This patch addresses the problem by comparing all flags except VM_LOCKED
when deciding if pagetables should be shared or not for hugetlbfs-backed
mapping.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Acked-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: <stable@kernel.org>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: <starlight@binnacle.cx>
Cc: Eric B Munson <ebmunson@us.ibm.com>
Cc: Adam Litke <agl@us.ibm.com>
Cc: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

:040000 040000 8217826c66b5568797d32704c6f7a75a0a30afd8
5863b96c01e1549fa41635a2fcfdf26df7b4dc7d M arch
Comment by Anton Johansson (antjoh) - Thursday, 30 July 2009, 20:27 GMT
I have been experiencing very much the same problem. With the rt73 wifi usb dongle inserted I get a kernel oops when trying to start X (though only with the nvidia driver). Without the rt73 module loaded everything runs fine.

More info in this thread (which also contains the oops message): http://bbs.archlinux.org/viewtopic.php?id=76890

Loading...