Re: 2.6.29-rc6-rt3 crash on PXA270

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 06, 2009 at 05:33:57PM -0500, Cliff Brake wrote:
> Hello,
> 
> I'm using running code from the following source:
> 
>    git://git.pengutronix.de/git/ukl/linux-2.6.git rt-master
> 
> and getting the below trace on a PXA270.
> 
> Is 2.6.29-rc6-rt3 stable on ARM?  Should this work?  Any suggestions
> for debugging?
Up to now it only compiles.  
> 
> It seems this fault occurred while udevd was loading, so it might be a
> driver issue.
> 
> Thanks,
> Cliff
> 
> -- 
> =======================
> Cliff Brake
> http://bec-systems.com
> 
> INIT: version 2.86 booting
> Starting udevudevd[514]: lookup_group: specified group 'scanner' unknown
> 
> udevd[514]: lookup_group: specified group 'scanner' unknown
> 
> udevd[514]: lookup_group: specified group 'scanner' unknown
> 
> udevd[514]: lookup_group: specified group 'scanner' unknown
> 
> udevd[514]: lookup_group: specified group 'nvram' unknown
> 
> udevd[514]: lookup_user: specudevd version 124 started
> ified user 'tss' unknown
> 
> udevd[514]: lookup_group: specified group 'tss' unknown
> 
> udevd[514]: lookup_group: specified group 'fuse' unknown
> 
> udevd[514]: lookup_group: specified group 'kvm' unknown
> 
> udevd[514]: lookup_group: specified group 'rdma' unknown
> 
> udevd[514]: lookup_group: specified group 'rdma' unknown
> 
> udevd[514]: lookup_group: specified group 'rdma' unknown
This is not the kernel's fault.  I assume you know how to fix it :-)

> Unable to handle kernel NULL pointer dereference at virtual address 00000000
This is triggered by BUG().

> pgd = c0004000
> [00000000] *pgd=00000000
> Internal error: Oops: 817 [#1] PREEMPT
> Modules linked in:
> CPU: 0    Not tainted  (2.6.29-rc6-rt3 #185)
> PC is at exit_mmap+0x1a4/0x1bc
> LR is at rt_spin_lock_slowunlock+0x50/0xa8
> pc : [<c0084650>]    lr : [<c0242090>]    psr: 20000013
> sp : c3943ee8  ip : c3943e78  fp : c3943f14
> r10: 0001c168  r9 : 00000001  r8 : c0027024
> r7 : c2ec6200  r6 : 00000000  r5 : 00000000  r4 : c2ec6040
> BUG: scheduling while atomic: mount.sh/0x00000001/553, CPU#0
If I read it correctly it's just a sleeping lock taken after a
rt_spinlock.  That is the type of some locks needs fixing.

Best regards,

Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux