Re: kernel panic and then oops
Hi Aaron, > Unable to handle kernel paging > request at virtual address b9e9168a This message is comming because a page fault has occured at virtual address b9e9168a . This means the requested page was not available in the virtual memory. When i got these kind of errors in my WLAN driver kernel was crashing. After decoding the oops i found out that i was tryng to free some invalid memory !! Once i fixed this bug my module was working fine. Regards, Lavin Aaron P. Martinez wrote: I am running Centos 4 with the latest kernel (updated yesterday) 2.6.9-5.0.5.EL on a P4 2.4 machine w/1 Gb ram and for the last couple weeks the machine has just been randomly hanging. I did upgrade the memory from a 512m stick to 2 1 gig sticks because the machine was regularly using 100% of the swap and would simply crawl. I know the thing to look at here obviously is the memory but i've already run memtest86+ and it reported that there was nothing wrong with the memory. I have tried running with a single stick of the 1Gb for the last couple days and tomorrow will be putting the 512 back in just for testing. I searched the archives for the error, but as far as kernel debugging goes, i'm very new to it. I saw a lot of errors that looked similar but as i'm not exactly sure how to read all of the data from a crash I hoped i could get some help from the experts. Generally when the machine hangs i get __nothing__ in the logs as far as a crash trace goes...the machine just seems to hang (sometimes i can ping it..other times not) and a hard reset is forced. When it comes up..the log is void of any info. Today the machine reset, I wasn't onsite, but as it was hanging i got the onsite person to give me the error: <0> kernel panic not syncing: fatal exception in interrupt <0> kernel panic not syncing: arch/i386/kernel/irq.c:590 spin_is_locked on initialized spinlock C03a5098 I'm sure there was other messages but this is all i got from him before he needed to get the machine running again. He reset the machine and about 2 minutes later the following messages showed up in the log: Unable to handle kernel paging request at virtual address b9e91c8a Apr 21 16:12:44 wolverine kernel: printing eip: Apr 21 16:12:44 wolverine kernel: f88aed9a Apr 21 16:12:44 wolverine kernel: *pde = Apr 21 16:12:44 wolverine kernel: Oops: 0002 [#1] Apr 21 16:12:44 wolverine kernel: Modules linked in: md5 ipv6 autofs4 iptable_mangle iptable_nat ipt_LOG ipt_state ip_conntrack iptable_filter ip_tables uhci_hcd ehci_hcd 8139too mii floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod Apr 21 16:12:44 wolverine kernel: CPU:0 Apr 21 16:12:44 wolverine kernel: EIP:0060:[]Not tainted VLI Apr 21 16:12:44 wolverine kernel: EFLAGS: 00010246 (2.6.9-5.0.5.EL) Apr 21 16:12:44 wolverine kernel: EIP is at ext3_try_to_allocate_with_rsv+0xd1/0x358 [ext3] Apr 21 16:12:44 wolverine kernel: eax: ebx: f7e01aa8 ecx: 00158000 edx: Apr 21 16:12:44 wolverine kernel: esi: e85bb669 edi: 7000 ebp: esp: e64abbd5 Apr 21 16:12:44 wolverine kernel: ds: 007b es: 007b ss: 0068 Apr 21 16:12:44 wolverine kernel: Process imapd (pid: 3502, threadinfo=e64ab000 task=e3ae38f0) Apr 21 16:12:44 wolverine kernel: Stack: 2b001580 9400 00f69a32 00f6e4d8 00f6e4d8 0100 Apr 21 16:12:44 wolverine kernel:00f6e104 00f7e01a 0070 5bf6e4d8 ecf88af2 00f5d512 6870 4ce85bb6 Apr 21 16:12:44 wolverine kernel:e4e64abc 80c02a10 2bf500fc 6800 00e85bb6 60f6e104 00f6e785 Apr 21 16:12:44 wolverine kernel: Call Trace: Apr 21 16:12:44 wolverine kernel: Code: 8d 98 a8 00 00 00 8b 42 14 01 c1 89 4c 24 04 8b 56 00 80 14 24 8b 46 34 89 44 24 14 8b 46 38 89 44 24 00 8b 04 24 8b 14 24 22 06 <18> 83 e2 01 09 c2 64 84 83 7c 24 18 00 74 20 84 ed 78 1c ff 74 Apr 21 16:12:44 wolverine kernel: <1>Unable to handle kernel paging request at virtual address b9e9168a Apr 21 16:12:44 wolverine kernel: printing eip: Apr 21 16:12:44 wolverine kernel: f88aed9a Apr 21 16:12:44 wolverine kernel: *pde = Apr 21 16:12:44 wolverine kernel: Oops: 0002 [#2] Apr 21 16:12:44 wolverine kernel: Modules linked in: md5 ipv6 autofs4 iptable_mangle iptable_nat ipt_LOG ipt_state ip_conntrack iptable_filter ip_tables uhci_hcd ehci_hcd 8139too mii floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod Apr 21 16:12:44 wolverine kernel: CPU:0 Apr 21 16:12:44 wolverine kernel: EIP:0060:[]Not tainted VLI Apr 21 16:12:44 wolverine kernel: EFLAGS: 00010206 (2.6.9-5.0.5.EL) Apr 21 16:12:44 wolverine kernel: EIP is at ext3_try_to_allocate_with_rsv+0xd1/0x358 [ext3] Apr 21 16:12:44 wolverine kernel: eax: 0430 ebx: f7e014a8 ecx: 00048000 edx: 04b0 Apr 21 16:12:44 wolverine kernel: esi: f3f0ccd1 edi: 2f54 ebp: esp: f5f4fbd5 Apr 21 16:12:44 wolverine kernel: ds: 007b es: 007b ss: 0068 Apr 21 16:12:44 wolverine kernel: Process cleanup (pid: 2005, threadinfo=f5f4f000 task=f594e1b0) Ap
Re: Linux kernel TI TLAN driver
Can you send me the oops capture ?? Atro Tossavainen wrote: Hi, I got my hands on a Texas Instruments ThunderLAN PCI 100 Mbit card (PCI ID 104c:0500), which is what SGI are supplying if you want a second NIC in your O2. It appears that this card is not supported by the tlan driver in the Linux kernel (at least not in 2.4.29, which is what I am using on the machine I tried it on). Patching the driver with the relevant PCI IDs allowed the detection of the card, as shown in dmesg: ThunderLAN driver v1.15 TLAN: eth0 irq=15, io=8400, Compaq NetFlex-3/E, Rev. 48 TLAN: 1 device installed, PCI: 1 EISA: 0 and in "ifconfig eth0": eth0Link encap: Ethernet HWaddr 00:00:58:01:55:53 (and the rest of the normal stuff) but trying to configure the interface with an address and bringing it up caused a kernel oops. (This is on Alpha.) # ifconfig eth0 inet blah... up Unable to handle kernel paging request at virtual address 093fcb04 Segmentation fault In dmesg, there is an ifconfig(4218): Oops 0 followed by a register dump, a trace, and some code. Any ideas? -- P.Lavin Software Engineer, Redpine Signals ,Inc. Hyderabad. http://www.redpinesignals.com - 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/
wireless lan, defragmentation in driver module.
Hi, I need help in the following issue, i'll explain the mechanisum & the problem i'm facing, 1) In the existing wireless lan driver we've MPDU's & MSDU's, all the MPDU's are handled by the firmware where as all the MSDU's by the driver. Now i need to implement 802.11E protocol based block ack mechanisum, in this mechanisum ther will not be any wirelss ack's for each MPDU's insted the Transmitter can request for Blockack by transmitting BlockAck.request , for which the receiver will respond with an block ack by indication all the lost mpdu's. The MSDU's given by the driver/os can be fragmented in the MAC(by firmware) if the packet is exceeding the fragmentation threshold limit. Previously the defragmentation was done in firmware but as firmware is lacking memory we've to move the de-fragmentation (only in block ack mechansum) into driver. In the old driver this was not a problem because driver will get only MSDU's & not MPDU's. So that i can happely copy these packets from our h/w queue into an sk_buff & give it to OS, a) in the present case i cannot do this if block.ack mechanisum was established, i'll get only mpdu's & i've to assemble it & form the MSDU's. b) I'll have a scheduler who'll come & take these packets from my software queue's & give it to OS. So i need to know a) whenever i've 10mpdu's of an MSDU from Station A to be transmitted into StationB A B mpdu1>Success mpdu2>Success mpdu3>Success mpdu4>Failed mpdu5>Success mpdu6>Success mpdu7>Failed mpdu8>Success mpdu9>Failed mpdu10>Success mpdu's 3, 7 & 9 are lost this we'll indicate in the block-acksent whenever transmitter is requesting for block ack using blockack.request , but in the receiver all these mpdu's has to be stored untill station A succesfully transmits all the lost mpdu's. Once these mpdu's are received correctly i've to put these mpdu's in the correct position & form the MSDU, then only i can give this MSDU to OS. This is the scenario which can happen in a simple MSDU transfer from station A to B. Is it possible to allocate one skbuff for one packet (this will be mainatained in my s/w queues), as & when some mpdu's come i'll insert it in the correct offset ??Weather any kernel calls are available for manipulating skbuff. i searched in net/core.c but i was not sure weather this can be used in my own de-fragmentation mechanism... Or should i directly maintain my own buffers & copy it only in the end to a single skbuff, i dont think this a good way coz this will decrease the performance of the mechanisum !!! Can anyone help me ! Regards, P.Lavin - 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/
wireless lan, defragmentation in driver module.
Hi, I need help in the following issue, i'll explain the mechanisum & the problem i'm facing, 1) In the existing wireless lan driver we've MPDU's & MSDU's, all the MPDU's are handled by the firmware where as all the MSDU's by the driver. Now i need to implement 802.11E protocol based block ack mechanisum, in this mechanisum ther will not be any wirelss ack's for each MPDU's insted the Transmitter can request for Blockack by transmitting BlockAck.request , for which the receiver will respond with an block ack by indication all the lost mpdu's. The MSDU's given by the driver/os can be fragmented in the MAC(by firmware) if the packet is exceeding the fragmentation threshold limit. Previously the defragmentation was done in firmware but as firmware is lacking memory we've to move the de-fragmentation (only in block ack mechansum) into driver. In the old driver this was not a problem because driver will get only MSDU's & not MPDU's. So that i can happely copy these packets from our h/w queue into an sk_buff & give it to OS, a) in the present case i cannot do this if block.ack mechanisum was established, i'll get only mpdu's & i've to assemble it & form the MSDU's. b) I'll have a scheduler who'll come & take these packets from my software queue's & give it to OS. So i need to know a) whenever i've 10mpdu's of an MSDU from Station A to be transmitted into StationB A B mpdu1>Success mpdu2>Success mpdu3>Success mpdu4>Failed mpdu5>Success mpdu6>Success mpdu7>Failed mpdu8>Success mpdu9>Failed mpdu10>Success mpdu's 3, 7 & 9 are lost this we'll indicate in the block-acksent whenever transmitter is requesting for block ack using blockack.request , but in the receiver all these mpdu's has to be stored untill station A succesfully transmits all the lost mpdu's. Once these mpdu's are received correctly i've to put these mpdu's in the correct position & form the MSDU, then only i can give this MSDU to OS. This is the scenario which can happen in a simple MSDU transfer from station A to B. Is it possible to allocate one skbuff for one packet (this will be mainatained in my s/w queues), as & when some mpdu's come i'll insert it in the correct offset ??Weather any kernel calls are available for manipulating skbuff. i searched in net/core.c but i was not sure weather this can be used in my own de-fragmentation mechanism... Or should i directly maintain my own buffers & copy it only in the end to a single skbuff, i dont think this a good way coz this will decrease the performance of the mechanisum !!! Can anyone help me ! Regards, P.Lavin - 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/
Re: no need to check for NULL before calling kfree() -fs/ext2/
Hi,
In my wlan driver module, i allocated some memory using kmalloc in
interrupt context, this one failed but its not returning NULL , so i was
proceeding further everything was going wrong... & finally the kernel
crahed. Can any one of you tell me why this is happening ? i cannot use
GFP_KERNEL because i'm calling this function from interrupt context & it
may block. Any other solution for this ?? I'm concerned abt why kmalloc
is not returning null if its not a success ??
Is it not necessary to check for NULL before calling kfree() ??
Regards,
Lavin
Pekka J Enberg wrote:
Hi,
Paul Jackson writes:
Even such obvious changes as removing redundant checks doesn't
seem to ensure a performance improvement. Jesper Juhl posted
performance data for such changes in his microbenchmark a couple
of days ago.
It is not a performance issue, it's an API issue. Please note that
kfree() is analogous libc free() in terms of NULL checking. People are
checking NULL twice now because they're confused whether kfree() deals
it or not.
Paul Jackson writes:
Maybe we should be following your good advice:
> You don't know that until you profile!
instead of continuing to make these code changes.
I am all for profiling but it should not stop us from merging the
patches because we can restore the generated code with the included
(totally untested) patch.
Pekka
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
Index: 2.6/include/linux/slab.h
===
--- 2.6.orig/include/linux/slab.h 2005-03-22 14:31:30.0
+0200
+++ 2.6/include/linux/slab.h2005-03-30 09:08:13.0 +0300
@@ -105,8 +105,14 @@
return __kmalloc(size, flags);
}
+static inline void kfree(const void * p)
+{
+ if (!p)
+ return;
+ __kfree(p);
+}
+
extern void *kcalloc(size_t, size_t, int);
-extern void kfree(const void *);
extern unsigned int ksize(const void *);
extern int FASTCALL(kmem_cache_reap(int));
Index: 2.6/mm/slab.c
===
--- 2.6.orig/mm/slab.c 2005-03-22 14:31:31.0 +0200
+++ 2.6/mm/slab.c 2005-03-30 09:08:45.0 +0300
@@ -2567,13 +2567,11 @@
* Don't free memory not originally allocated by kmalloc()
* or you will run into trouble.
*/
-void kfree (const void *objp)
+void __kfree (const void *objp)
{
kmem_cache_t *c;
unsigned long flags;
- if (!objp)
- return;
local_irq_save(flags);
kfree_debugcheck(objp);
c = GET_PAGE_CACHE(virt_to_page(objp));
@@ -2581,7 +2579,7 @@
local_irq_restore(flags);
}
-EXPORT_SYMBOL(kfree);
+EXPORT_SYMBOL(__kfree);
#ifdef CONFIG_SMP
/**
-
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/
-
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/
Re: no need to check for NULL before calling kfree() -fs/ext2/
Hi Jesper,
I'm sending this mail to mailing list coz in my company we have some
restrictions on o/g mails, Sorry for that...
Lemme ask u smthing, herez the code
199 sndpkt = (RSI_sndpkt_t *) RSI_MALLOC(sizeof(RSI_sndpkt_t));
200 sndpkt->buf_list = (RSI_buf_t *) RSI_MALLOC(sizeof(RSI_buf_t));
Here if malloc fails sndpkt->buf_list should be null right ?? & if i
proceed further ..
201 sndpkt->buf_list->start_addr = buf;
202 sndpkt->buf_list->length = length;
Here itself this should crash right ?? But its not crashing here !!! Wt
was happening was
201 sndpkt->buf_list->start_addr = buf; was not getting initailised & wn
we try to access this variable latter
this was crashing.
Actally i'm not checking for return value from kmalloc thatz a mistake,
I'll fix this but why is it not crashing in line # 201 ??
Jesper Juhl wrote:
On Wed, 30 Mar 2005, P Lavin wrote:
Date: Wed, 30 Mar 2005 12:45:01 +0530
From: P Lavin <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Subject: Re: no need to check for NULL before calling kfree() -fs/ext2/
Hi,
In my wlan driver module, i allocated some memory using kmalloc in interrupt
context, this one failed but its not returning NULL ,
kmalloc() should always return NULL if the allocation failed.
so i was proceeding
further everything was going wrong... & finally the kernel crahed. Can any one
of you tell me why this is happening ? i cannot use GFP_KERNEL because i'm
calling this function from interrupt context & it may block. Any other
If you need to allocate memory from interrupt context you should be using
GFP_ATOMIC (or, if possible, do the allocation earlier in a different
context).
I'm using this flag only, this flag does not guarentee mem allocation,
right ??
solution for this ?? I'm concerned abt why kmalloc is not returning null if
its not a success ??
I have no explanation for that, are you sure that's really what's
happening?
I'm not checking this , but my explanation is given above.
Is it not necessary to check for NULL before calling kfree() ??
No, it is not nessesary to check for NULL before calling kfree() since
kfree() does
void kfree (const void *objp)
{
...
if (!objp)
return;
...
}
So, if you pass kfree() a NULL pointer it deals with it itself, you don't
need to check that explicitly before calling kfree() - that's redundant.
Regs,
Lavin
-
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/
