kernel crash after adding ethernet driver
Meher
I am working on a MIPS32 based system with Linux 2.6.10 on it
(yep.. it is old :( ). I am working on migrating to the new version. I
have a written an ethernet driver for a custom ethenet chip and I am
able to send and receive packets through the interface. When I set
kernel to Auto IP config I can also see that kernel gets an IP address
assigned. But after some time kernel crashes giving a message ".BUG:
sleeping function called from invalid context events/0(4) at
arch/mips/math-emu/dsemul.c". This problem does not appear when I am
not using the ethernet driver (disable ethernet interface). I looked
at the RX/TX path and I am using Old API interface in the ethernet
driver. I am not calling any functions that can sleep.
Can anyone sugest me how to debug the problem? Please let me know if
you need more information.
This is the kernel log:
Booting...
Launching kernel decompressor.
Starting GZIP Uncompression Algorithm.
Kernel decompressor was successful ... launching kernel.
LINUX started...
Entering start_kernel
Linux version 2.6.10_dev-malta-mips2_fp_len (me...@xxx.xxxxx.com) (gcc
version 3.4.3 ) #271 Mon Apr 30 16:13:53 CDT 2007
CPU revision is: 00018448
Determined physical RAM map:
memory: 14001000 @ 00000000 (reserved)
memory: 0001f000 @ 14001000 (ROM data)
memory: 00243000 @ 14020000 (reserved)
memory: 01d9d000 @ 14263000 (usable)
Built 1 zonelists
Kernel command line: console=ttyS0,9600n81 root=/dev/mtdblock0
rootfstype=jffs2 rw
Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Primary data cache 8kB, 4-way, linesize 16 bytes.
Synthesized TLB refill handler (20 instructions).
Synthesized TLB load handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
PID hash table entries: 256 (order: 8, 4096 bytes)
CPU frequency 187.50 MHz
Using 93.750 MHz high precision timer.
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Freeing Bootloader reserved memory [0x0001f000 @ 0x14001000]
Memory: 30080k/32768k available (1662k kernel code, 2644k reserved,
438k data, 112k init)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Checking for 'wait' instruction... available.
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
softirq RT prio: 24.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
Can't analyze prologue code at 941bd670
EFS: 1.0a - http://aeschi.ch.eu.org/efs/
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 5 ports, IRQ sharing disabled
ttyS0 at MMIO 0x0 (irq = 15) is a 16550A
io scheduler noop registered
loop: loaded (max 8 devices)
Currently in Ceswitch_Probe
Platform device register completed
Driver register completed
Alloc Netdev completed
In ceswitch_dev_init
Out ceswitch_dev_init
In eswitch_dev_get_net_stats
CESWITCH:Installed ceswitch
elevator: using noop as default io scheduler
avalanche flash device: 0x1000000 at 0x10000000.
Primary flash device: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
Primary flash device: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Looking for mtd device :mtd0:
flash_base and flash_end for mtd0 are: 90120000,90320000
Found a mtd0 image (0x120000), with size (0x200000).
Creating 1 MTD partitions on "Primary flash device":
0x00120000-0x00320000 : "mtd0"
Looking for mtd device :mtd1:
flash_base and flash_end for mtd1 are: 90020000,90120000
Found a mtd1 image (0x20000), with size (0x100000).
Creating 1 MTD partitions on "Primary flash device":
0x00020000-0x00120000 : "mtd1"
Looking for mtd device :mtd2:
flash_base and flash_end for mtd2 are: 90000000,90020000
Found a mtd2 image (0x0), with size (0x20000).
Creating 1 MTD partitions on "Primary flash device":
0x00000000-0x00020000 : "mtd2"
Number of partitions detected: 3
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
********* In eswitch_open ***********
Calling initPhyReset
initPhyReset::Bringing DSP Out of Reset
initPhyReset::Bringing ESWITCH Out of Reset
initPhyReset::Reset the PHY
DSP CLock PLL Value is 0x427e
phyGetState[0]: link = 0, speed = 0, duplex = 0
phyGetState[1]: link = 0, speed = 0, duplex = 0
GIG PHYs detected, PHYID = 0x143bcb1
phyConfigurePort[0]: 0x00000100
Phy[0]: 0x00000100
phyConfigurePort[1]: 0x00000100
Phy[1]: 0x00000100
cesw0: Successfully installed IRQ: 41
eswitch_open::Checking for PhyStatechange for port : 0
phyState hasn't changed checking again for 1 th time
LINKCHANGE: PHY[0]: Link= 0000 --> 0001
LINKCHANGE: PHY[0]: Speed= 0000 --> 0020
LINKCHANGE: PHY[0]: Duplex= 0000 --> 0001
PHY[0] changed calling pswitchPortCfgChange(0)
phyGetState[0]: link = 1, speed = 32, duplex = 1
pswitch: MAC[0].speed = 100
pswitch: MAC[0].duplex = H
Kalyan::eswitch_open::Checking for PhyStatechange for port : 1
phyState hasn't changed checking again for 1 th time
Kalyan:: In eswitch_dev_get_net_stats
Kalyan:: In eswitch_dev_get_net_stats
Sending DHCP requests .In eswitch_dev_tx now.. calling pswitchSend
In pswitchSend..
pswitchSend::It is broadcast packet: 255
In pswitchSend..
pswitchSend:: dest = 0xffffffffffff
pswitchSend::It is broadcast packet: 255
OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 10.XX.X.XXX
IP-Config: Complete:
device=cesw0, addr=10.13.8.116, mask=255.255.255.240, gw=10.XX.X.XXX,
host=10.XX.X.XXX, domain=cisco.com, nis-domain=(none),
bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 112k freed
Running /bin/sh
Algorithmics/MIPS FPU Emulator v1.5
BusyBox v1.00 (2007.02.05-19:57+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
# ping
BusyBox v1.00 (2007.02.05-19:57+0000) multi-call binary
Usage: ping [OPTION]... host
# BUG: sleeping function called from invalid context events/0(4) at
arch/mips/math-emu/dsemul.c
:140
in_atomic():1 [00000001], irqs_disabled():1
Call Trace:
[<94043314>] __might_sleep+0x104/0x11c
[<94043008>] do_dsemulret+0x58/0x160
[<94043970>] task_rq_lock+0x38/0x54
[<9402db70>] do_ade+0x20/0x380
[<94027760>] handle_adel_int+0x38/0x58
[<9407c980>] drain_array_locked+0x78/0xd4
[<9407c808>] free_block+0x8c/0x18c
[<94246000>] ip_auto_config+0xa54/0x1184
[<9407c980>] drain_array_locked+0x78/0xd4
[<94246000>] ip_auto_config+0xa54/0x1184
[<9407dc10>] cache_reap+0xb4/0x320
[<941170d8>] flush_to_ldisc+0x0/0x1a0
[<941bc358>] schedule+0x58/0x158
[<9407db5c>] cache_reap+0x0/0x320
[<94060120>] worker_thread+0x254/0x384
[<941bba24>] __schedule+0x14c/0x980
[<940447e4>] default_wake_function+0x0/0x28
[<9405fecc>] worker_thread+0x0/0x384
[<9405fecc>] worker_thread+0x0/0x384
[<940668fc>] kthread+0x124/0x168
[<94028afc>] kernel_thread_helper+0x10/0x18
[<94028aec>] kernel_thread_helper+0x0/0x18
Unhandled kernel unaligned access in
arch/mips/kernel/unaligned.c::emulate_load_store_insn, line 475
[#1]:
Cpu 0
$ 0 : 00000000 1000fc00 9466d400 94266000
$ 4 : b43a0ba0 942d4320 ffffffff 00000001
$ 8 : 00000002 942fa1a4 00000000 942492b0
$12 : 00000000 fffffffb ffffffff 0000000a
$16 : 942d4320 942bda60 942bda6c 00000000
$20 : 00000001 ffd80000 80000000 94250000
$24 : 00000000 9400de18
$28 : 94016000 94017e70 00200200 9407c980
Hi : 00000010
Lo : 00000004
epc : 9407c808 free_block+0x8c/0x18c Not tainted
ra : 9407c980 drain_array_locked+0x78/0xd4
Status: 1000fc02 KERNEL EXL
Cause : 30800010
BadVA : 00000003
PrId : 00018448
Modules linked in:
Process events/0 (pid: 4, threadinfo=94016000, task=9401c8e0)
Stack : 941efa5c 00000000 942ebbe0 942ebbe0 942bda7c 94246000 942d4310 00000001
942d4320 942bdad0 942bd97c 94250000 00200200 00100100 94250000 9407c980
1000fc00 94004f28 94246000 942ebbe0 942bd97c 942bda60 00000001 9407dc10
941170d8 94004f10 94004f18 94004f20 94017ee8 941bc358 94253e24 94253e28
1000fc01 00000000 9407db5c 94004f10 94004f18 94004f20 94004f28 94060120
...
Call Trace:
[<94246000>] ip_auto_config+0xa54/0x1184
[<9407c980>] drain_array_locked+0x78/0xd4
[<94246000>] ip_auto_config+0xa54/0x1184
[<9407dc10>] cache_reap+0xb4/0x320
[<941170d8>] flush_to_ldisc+0x0/0x1a0
[<941bc358>] schedule+0x58/0x158
[<9407db5c>] cache_reap+0x0/0x320
[<94060120>] worker_thread+0x254/0x384
[<941bba24>] __schedule+0x14c/0x980
[<940447e4>] default_wake_function+0x0/0x28
[<9405fecc>] worker_thread+0x0/0x384
[<9405fecc>] worker_thread+0x0/0x384
[<940668fc>] kthread+0x124/0x168
[<94028afc>] kernel_thread_helper+0x10/0x18
[<94028aec>] kernel_thread_helper+0x0/0x18
Code: 00431021 00551021 8c46001c <8cc30004> 8cc20000 ac620000
ac430004 3c020010 34420100
note: events/0[4] exited with preempt_count 1
BUG: scheduling while atomic: events/0/0x00000001/4
caller is do_exit+0xbc8/0xf4c
Call Trace:
[<9404d208>] do_exit+0xbc8/0xf4c
[<941bbfcc>] __schedule+0x6f4/0x980
[<941bbfc4>] __schedule+0x6ec/0x980
[<9404d208>] do_exit+0xbc8/0xf4c
[<9402ce78>] __die_if_kernel+0x0/0x90
[<9402ceec>] __die_if_kernel+0x74/0x90
[<9402ced0>] __die_if_kernel+0x58/0x90
[<940621dc>] search_exception_tables+0x4c/0x5c
[<940311f4>] fixup_exception+0x24/0x60
[<9407c808>] free_block+0x8c/0x18c
[<9402dea8>] do_ade+0x358/0x380
[<9402de7c>] do_ade+0x32c/0x380
[<94027760>] handle_adel_int+0x38/0x58
[<9407c980>] drain_array_locked+0x78/0xd4
[<9407c808>] free_block+0x8c/0x18c
[<94246000>] ip_auto_config+0xa54/0x1184
[<9407c980>] drain_array_locked+0x78/0xd4
[<94246000>] ip_auto_config+0xa54/0x1184
[<9407dc10>] cache_reap+0xb4/0x320
[<941170d8>] flush_to_ldisc+0x0/0x1a0
[<941bc358>] schedule+0x58/0x158
[<9407db5c>] cache_reap+0x0/0x320
[<94060120>] worker_thread+0x254/0x384
[<941bba24>] __schedule+0x14c/0x980
[<940447e4>] default_wake_function+0x0/0x28
[<9405fecc>] worker_thread+0x0/0x384
[<9405fecc>] worker_thread+0x0/0x384
[<940668fc>] kthread+0x124/0x168
[<94028afc>] kernel_thread_helper+0x10/0x18
[<94028aec>] kernel_thread_helper+0x0/0x18
--
Regards,
Meher
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to eca...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
pradeep singh
> Hi,
> I am working on a MIPS32 based system with Linux 2.6.10 on it
> (yep.. it is old :( ). I am working on migrating to the new version. I
> have a written an ethernet driver for a custom ethenet chip and I am
> able to send and receive packets through the interface. When I set
> kernel to Auto IP config I can also see that kernel gets an IP address
> assigned. But after some time kernel crashes giving a message ".BUG:
> sleeping function called from invalid context events/0(4) at
> arch/mips/math-emu/dsemul.c". This problem does not appear when I am
Can you please recheck if you are not holding any spinlocks.Also check
if you are not doing a memory allocation with spinlock held or in
interrupt context.May be you are doing something like printk which may
sleep IMO.Rechcek any methods you are calling which may sleep.
HTH
Thanks
~psr
--
play the game
Rajat Jain
>
> Can you please recheck if you are not holding any spinlocks.Also check
> if you are not doing a memory allocation with spinlock held or in
> interrupt context.May be you are doing something like printk which may
> sleep IMO.Rechcek any methods you are calling which may sleep.
printk will not sleep. Thus it is safe to call printk from any where
except from very few restricted locations like some scheduler etc.
Thanks,
Rajat
pradeep singh
> Hi,
> >
> > Can you please recheck if you are not holding any spinlocks.Also check
> > if you are not doing a memory allocation with spinlock held or in
> > interrupt context.May be you are doing something like printk which may
> > sleep IMO.Rechcek any methods you are calling which may sleep.
>
> printk will not sleep. Thus it is safe to call printk from any where
> except from very few restricted locations like some scheduler etc.
Can you please help me out in understanding why?
Printk involves allocating buffer for the message to be printed,
right?Which can sleep, isnt it?
What am i missing here?
Thanks for the correction Rajat.
~psr
>
> Thanks,
>
> Rajat
>
--
play the game
Rajat Jain
> > > Can you please recheck if you are not holding any spinlocks.Also check
> > > if you are not doing a memory allocation with spinlock held or in
> > > interrupt context.May be you are doing something like printk which may
> > > sleep IMO.Rechcek any methods you are calling which may sleep.
> >
> > printk will not sleep. Thus it is safe to call printk from any where
> > except from very few restricted locations like some scheduler etc.
>
> Can you please help me out in understanding why?
> Printk involves allocating buffer for the message to be printed,
> right?Which can sleep, isnt it?
> What am i missing here?
No, printk does not allocate any buffer. printk has a compile time
circular buffer (log_buf) whose size is determined by compile time
constant. So what prink does is mere dump the message in this circular
buffer.
Thanks,
Rajat
pradeep singh
>
> > > > Can you please recheck if you are not holding any spinlocks.Also check
> > > > if you are not doing a memory allocation with spinlock held or in
> > > > interrupt context.May be you are doing something like printk which may
> > > > sleep IMO.Rechcek any methods you are calling which may sleep.
> > >
> > > printk will not sleep. Thus it is safe to call printk from any where
> > > except from very few restricted locations like some scheduler etc.
> >
> > Can you please help me out in understanding why?
> > Printk involves allocating buffer for the message to be printed,
> > right?Which can sleep, isnt it?
> > What am i missing here?
>
> No, printk does not allocate any buffer. printk has a compile time
> circular buffer (log_buf) whose size is determined by compile time
> constant. So what prink does is mere dump the message in this circular
> buffer.
this means you cannot just keep on priniting a lot of data using a
single printk right? May be log_buf has a buffer size limit because it
is a compile time constant.
What am i missing here?
Thanks
~psr
>
> Thanks,
>
> Rajat
>
--
play the game
--
Rajat Jain
> > No, printk does not allocate any buffer. printk has a compile time
> > circular buffer (log_buf) whose size is determined by compile time
> > constant. So what prink does is mere dump the message in this circular
> > buffer.
> Oh... got it.but this raises a silly doubt for me.
> this means you cannot just keep on priniting a lot of data using a
> single printk right? May be log_buf has a buffer size limit because it
> is a compile time constant.
> What am i missing here?
The buffer is circular. So there is no limit to the amount of messages
you can push. The only catch is if you push "too much", you will some
some of the msg (the oldest few characters).
Thanks,
Rajat
pradeep singh
>
> > > No, printk does not allocate any buffer. printk has a compile time
> > > circular buffer (log_buf) whose size is determined by compile time
> > > constant. So what prink does is mere dump the message in this circular
> > > buffer.
>
> > Oh... got it.but this raises a silly doubt for me.
> > this means you cannot just keep on priniting a lot of data using a
> > single printk right? May be log_buf has a buffer size limit because it
> > is a compile time constant.
> > What am i missing here?
>
> The buffer is circular. So there is no limit to the amount of messages
> you can push. The only catch is if you push "too much", you will some
> some of the msg (the oldest few characters).
Thanks for the clarification once again.
~psr
>
> Thanks,
>
> Rajat
>
--
play the game
--
Meher
On 5/1/07, pradeep singh <2500.p...@gmail.com> wrote:
> On 5/1/07, Meher <mail2...@gmail.com> wrote:
> > Hi,
> > I am working on a MIPS32 based system with Linux 2.6.10 on it
> > (yep.. it is old :( ). I am working on migrating to the new version. I
> > have a written an ethernet driver for a custom ethenet chip and I am
> > able to send and receive packets through the interface. When I set
> > kernel to Auto IP config I can also see that kernel gets an IP address
> > assigned. But after some time kernel crashes giving a message ".BUG:
> > sleeping function called from invalid context events/0(4) at
> > arch/mips/math-emu/dsemul.c". This problem does not appear when I am
>
> Can you please recheck if you are not holding any spinlocks.Also check
> if you are not doing a memory allocation with spinlock held or in
> interrupt context.May be you are doing something like printk which may
> sleep IMO.Rechcek any methods you are calling which may sleep.
>
The only spin locks I am holding are the spin_lock_irqsave and
spin_unlock_irqrestore when I enter and leave the ISR. Also the only
memory allocation call I am making in my driver in interrupt context
is the dev_alloc_skb() which I believe can be called from interrupt
context(as it internally uses GFP_ATOMIC flag). I am using printk's
but as per my understanding they should be safe. Until I call
netif_rx(skb) in my interrupt handler I am making sure I am not making
any kernel calls.. any pointers on how to know which call is making
this crash if I am missing something...
pradeep singh
> HI Pradeep,
>
> On 5/1/07, pradeep singh <2500.p...@gmail.com> wrote:
> > On 5/1/07, Meher <mail2...@gmail.com> wrote:
> > > Hi,
> > > I am working on a MIPS32 based system with Linux 2.6.10 on it
> > > (yep.. it is old :( ). I am working on migrating to the new version. I
> > > have a written an ethernet driver for a custom ethenet chip and I am
> > > able to send and receive packets through the interface. When I set
> > > kernel to Auto IP config I can also see that kernel gets an IP address
> > > assigned. But after some time kernel crashes giving a message ".BUG:
> > > sleeping function called from invalid context events/0(4) at
> > > arch/mips/math-emu/dsemul.c". This problem does not appear when I am
> >
> > Can you please recheck if you are not holding any spinlocks.Also check
> > if you are not doing a memory allocation with spinlock held or in
> > interrupt context.May be you are doing something like printk which may
> > sleep IMO.Rechcek any methods you are calling which may sleep.
> >
>
> The only spin locks I am holding are the spin_lock_irqsave and
> spin_unlock_irqrestore when I enter and leave the ISR. Also the only
> memory allocation call I am making in my driver in interrupt context
> is the dev_alloc_skb() which I believe can be called from interrupt
> context(as it internally uses GFP_ATOMIC flag).
Can you post the code?
That will be great to figure out the problem in a better way i guess.
I am using printk's
> but as per my understanding they should be safe.
Yes, they are safe. Sorry for the misunderstanding.
Thanks
~psr
--
play the game