Re: 2.6.test11 bug
From: Rafal Skoczylas
Date: Sun Dec 07 2003 - 22:46:38 EST
[ I am sorry if this message doesn't get threaded in the original
thread in your software, but I read lkml ocassionally through
usenet-gate so didn't have the original message in my mbox and
couldn't just hit "reply" ;) ]
On Mon, 08 Dec 2003 03:30:12 +0100 Gordon Cormack wrote:
> I have read the FAQ but I'm confused about how to report a 2.6
> kernel bug, or who to report it to.
> Dec 6 13:16:01 flax20 kernel: Bad page state at free_hot_cold_page
> Dec 6 13:16:01 flax20 kernel: flags:0x02000114 mapping:00000000
> mapped:1 count:0
I am experiencing similiar behaviour as described below.
In my case it is mlnetd (of mldonkey package) which seems to be
responsible for driving kernel to a crash.
After a few hours of running, either the process gets killed or system
crashes (I am only able to reboot it with alt+prntscr+b, but it seems
like it is not able to [S]ync or [U]nmount filesystems - i have lost
a few files which were open at the time of crash).
It may be worth to mention that I don't remember having such a crash
on 2.6.0-test9 which i used for a couple of weeks (since first day
it apeared on ftp.kernel.org untill test11 - i skipped test10).
ALi M1647, Duron 1200, 512MB sdram.
Linux poziomka 2.6.0-test11 #32 Fri Dec 5 21:10:40 CET 2003 i686
AMD_Duron(TM)Processor unknown Shameless Compilation
Compiled with gcc-3.3.2.
--- The last time, i got the following:
Bad page state at free_hot_cold_page
flags:0x01020008 mapping:d38afe68 mapped:0 count:0
Trying to fix it up, but a reboot is needed
--- But sometimes it get things like this:
Unable to handle kernel paging request at virtual address 5a85fb5c
*pde = 00000000
Oops: 0002 [#1]
EIP: 0060:[remove_wait_queue+36/112] Not tainted
EIP is at remove_wait_queue+0x24/0x70
eax: defb4000 ebx: da85fb58 ecx: 5a85fb58 edx: db0468b0
esi: db0468bc edi: 00000292 ebp: defb5fa0 esp: defb5f58
ds: 007b es: 007b ss: 0068
Process mlnetd (pid: 1456, threadinfo=defb4000 task=dd72e100)
Stack: db0468ac db046008 db046000 c0167484 00000000 cad86c08 00000001 c01681f5
defb5fa0 cad86c00 defb5fa0 00000041 defb4000 08376b48 cad86c08 00000000
cad86c00 00000001 c01674b0 db046000 00000000 3fd32b9c 083767d8 00000001
Code: 89 59 04 89 0b c7 46 04 00 02 20 00 c7 42 0c 00 01 10 00 57
<6>note: mlnetd exited with preempt_count 1
bad: scheduling while atomic!
(this last Call Trace repeted 2 more times)
If there is any important information missing, feel free to ask.
 Actually, I am not sure, but this is the only candidate because
it uses more and more memory over the time and the crash or kill occurs
more or less at the same level of memory usage (~10-12% of 512Meg).
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
nils 1781 11.1 10.5 41252 38796 pts/2 S 03:39 3:15 mlnetd
 The files loss is probably XFS-related problem.
"Blessed is the man, who having nothing to say, abstains from giving wordy
evidence of the fact." -- http://secprog.org/who/rs/quote.php?id=1
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/