Dave Airlie wrote:
EIP is at sysfs_release+0x34/0x80
eax: 00000001 ebx: dc7c2000 ecx: d1979860 edx: 00000001
esi: 762f7373 edi: d5ba26a0 ebp: d9368544 esp: dc7c3f80
ds: 007b es: 007b ss: 0068
Process udev (pid: 31802, threadinfo=dc7c2000 task=c7c19040)
Stack: df468c40 df798140 dffe4140 c0153c08 d5a9edbc df468c40 df798140
00000000
dc7c2000 c01523d3 00000000 00000003 080ac568 00000003 c0103101
00000003
080ac568 00000004 080ac568 00000003 08057198 00000006 0000007b
0000007b
Call Trace:
[<c0153c08>] __fput+0xf8/0x110
[<c01523d3>] filp_close+0x43/0x70
[<c0103101>] syscall_call+0x7/0xb
Code: 8b 41 0c 8b 40 48 8b 58 14 8b 41 48 8b 40 14 85 db 8b 70 04 74 07
89 d8 e8 9a 11 02 00 85 f6 74 1f bb 00 e0 ff ff 21 e3 ff 43 14 <ff> 8e
00 01 00 00 83 3e 02 74 32 8b 43 08 ff 4b 14 a8 08 75 21
<6>note: udev[31802] exited with preempt_count 1
Gee we get a lot of these, and no idea which sysfs file caused it.
How about we record the most-recently-opened sysfs file and display that at
oops time? (-mm only)
Looks good to me, I really have no idea of what is causing this, and
haven't seen any reports of this on mainline.
thanks,
greg k-h
Actually, I'm running a kernel straight from Linus' GIT repository.
EFLAGS: 00010202 (2.6.13-rc2-GIT-08-7-2005-0)
I can't reproduce (nothing new there...) if you can test with the
patch Andrew suggested, and let us know what occurs.. I thought this
was DRM related from another report but maybe he just had two bugs
(one DRM related misconfiguration, and something else)..
Dave.
I can't reproduce it either, and he said the patch was for -mm only.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|