[PATCH] e820 memory detection fix for ThinkPad
Hi Linus, Alan, lkml-readers, I first sent this two weeks ago, but other than a suggestion from a linux-kernel reader, I got no response. This small patch didn't appear in a 2.4.0-test kernel either, so I'm just submitting it again. This is a tiny patch to make the int15/e820 memory mapping work on IBM ThinkPads. Until now, I have had to give lilo a mem= option with one meg of RAM less than I actually have; otherwise ACPI events would overwrite data. The only alternative was to use one of the patches available on http://www.pell.portland.or.us/~orc/Memory/, but these are quite big. I tracked down the problem, at least for the ThinkPad 600X (2645-4EU), to arch/i386/boot/setup.S: apparently the bios doesn't retain the value of register %edx, so after the first entry is read the ascii word `SMAP' is lost and further entries won't be recognized. The solution is simple, just move the assignment 6 lines down so it's inside the loop that is done for every entry. This patch is for 2.4.0-test7..12, but it should work for pre13 kernels and even 2.2 kernels with the memory map backport: --- linux/arch/i386/boot/setup.S.origMon Oct 30 17:44:29 2000 +++ linux/arch/i386/boot/setup.S Thu Dec 21 19:37:12 2000 @@ -289,10 +289,11 @@ # a whole bunch of different types, and allows memory holes and # everything. We scan through this memory map and build a list # of the first 32 memory areas, which we return at [E820MAP]. -# +# This is documented at http://www.teleport.com/~acpi/acpihtml/topic245.htm + +#define SMAP 0x534d4150 meme820: -movl $0x534d4150, %edx# ascii `SMAP' xorl %ebx, %ebx # continuation counter movw $E820MAP, %di# point into the whitelist # so we can have the bios @@ -300,13 +301,15 @@ jmpe820: movl $0xe820, %eax# e820, upper word zeroed +movl $SMAP, %edx # do this every time, some + # bioses are forgetful movl $20, %ecx # size of the e820rec pushw %ds # data record. popw %es int $0x15# make the call jc bail820 # fall to e801 if it fails -cmpl $0x534d4150, %eax# check the return is `SMAP' +cmpl $SMAP, %eax # check the return is `SMAP' jne bail820 # fall to e801 if it fails # cmpl $1, 16(%di) # is this usable memory? My ThinkPad now shows this during boot: Linux version 2.4.0-test12 (mjoosen@hexane) (gcc version 2.95.2 19991024 (release)) #2 Sun Dec 10 23:51:04 EST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0bed @ 0010 (usable) BIOS-e820: f000 @ 0bfd (ACPI data) BIOS-e820: 1000 @ 0bfdf000 (ACPI NVS) BIOS-e820: 0002 @ 0bfe (reserved) BIOS-e820: 0002 @ fffe (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009f800 for 4096 bytes. ... and that's without a mem= option to lilo, of course. May I suggest you try this patch in the next 2.[24]-pre kernel? Thanks, and a happy New Year! (And be careful with fireworks, you need those fingers.) BTW: I work for IBM, but I'm not in the PC department (or even ThinkPad development). Unfortunately I won't be able to answer all your IBM-related questions... BTW2: I'm not on the linux-kernel mailing list, so please reply to [EMAIL PROTECTED] Regards, -- Marc Joosen Communication Link Design IBM T.J. Watson Research Center Yorktown Heights, NY - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] e820 memory detection fix for ThinkPad
Hi Linus, Alan, lkml-readers, I first sent this two weeks ago, but other than a suggestion from a linux-kernel reader, I got no response. This small patch didn't appear in a 2.4.0-test kernel either, so I'm just submitting it again. This is a tiny patch to make the int15/e820 memory mapping work on IBM ThinkPads. Until now, I have had to give lilo a mem= option with one meg of RAM less than I actually have; otherwise ACPI events would overwrite data. The only alternative was to use one of the patches available on http://www.pell.portland.or.us/~orc/Memory/, but these are quite big. I tracked down the problem, at least for the ThinkPad 600X (2645-4EU), to arch/i386/boot/setup.S: apparently the bios doesn't retain the value of register %edx, so after the first entry is read the ascii word `SMAP' is lost and further entries won't be recognized. The solution is simple, just move the assignment 6 lines down so it's inside the loop that is done for every entry. This patch is for 2.4.0-test7..12, but it should work for pre13 kernels and even 2.2 kernels with the memory map backport: --- linux/arch/i386/boot/setup.S.origMon Oct 30 17:44:29 2000 +++ linux/arch/i386/boot/setup.S Thu Dec 21 19:37:12 2000 @@ -289,10 +289,11 @@ # a whole bunch of different types, and allows memory holes and # everything. We scan through this memory map and build a list # of the first 32 memory areas, which we return at [E820MAP]. -# +# This is documented at http://www.teleport.com/~acpi/acpihtml/topic245.htm + +#define SMAP 0x534d4150 meme820: -movl $0x534d4150, %edx# ascii `SMAP' xorl %ebx, %ebx # continuation counter movw $E820MAP, %di# point into the whitelist # so we can have the bios @@ -300,13 +301,15 @@ jmpe820: movl $0xe820, %eax# e820, upper word zeroed +movl $SMAP, %edx # do this every time, some + # bioses are forgetful movl $20, %ecx # size of the e820rec pushw %ds # data record. popw %es int $0x15# make the call jc bail820 # fall to e801 if it fails -cmpl $0x534d4150, %eax# check the return is `SMAP' +cmpl $SMAP, %eax # check the return is `SMAP' jne bail820 # fall to e801 if it fails # cmpl $1, 16(%di) # is this usable memory? My ThinkPad now shows this during boot: Linux version 2.4.0-test12 (mjoosen@hexane) (gcc version 2.95.2 19991024 (release)) #2 Sun Dec 10 23:51:04 EST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0bed @ 0010 (usable) BIOS-e820: f000 @ 0bfd (ACPI data) BIOS-e820: 1000 @ 0bfdf000 (ACPI NVS) BIOS-e820: 0002 @ 0bfe (reserved) BIOS-e820: 0002 @ fffe (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009f800 for 4096 bytes. ... and that's without a mem= option to lilo, of course. May I suggest you try this patch in the next 2.[24]-pre kernel? Thanks, and a happy New Year! (And be careful with fireworks, you need those fingers.) BTW: I work for IBM, but I'm not in the PC department (or even ThinkPad development). Unfortunately I won't be able to answer all your IBM-related questions... BTW2: I'm not on the linux-kernel mailing list, so please reply to [EMAIL PROTECTED] Regards, -- Marc Joosen Communication Link Design IBM T.J. Watson Research Center Yorktown Heights, NY - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: e820 memory detection fix for ThinkPad
David Weinhall wrote: > On Tue, Dec 19, 2000 at 07:16:40PM -0500, Marc Joosen wrote: > > > > This is a tiny patch to make the int15/e820 memory mapping work on IBM > > ThinkPads. Until now, I have had to give lilo a mem= option with one meg > > If this simple patch solves your problem, great! But in that case, > PLEASE add a note telling WHY the assignment is done for every > iteration; else some smarthead will probably submit a patch someday > in the future along the lines of "assigning this only once makes the > loop faster"... > > Anyhow, good spotting! Thanks for the tip, David. I hope that whoever wants to move that line out of the loop is aware that it is only executed ~10 times :) So I hereby submit a second version of the patch, that includes a link to the documentation and #defines the word SMAP (thanks to David Parsons for that): --- linux/arch/i386/boot/setup.S.origMon Oct 30 17:44:29 2000 +++ linux/arch/i386/boot/setup.S Thu Dec 21 19:37:12 2000 @@ -289,10 +289,11 @@ # a whole bunch of different types, and allows memory holes and # everything. We scan through this memory map and build a list # of the first 32 memory areas, which we return at [E820MAP]. -# +# This is documented at http://www.teleport.com/~acpi/acpihtml/topic245.htm + +#define SMAP 0x534d4150 meme820: -movl $0x534d4150, %edx# ascii `SMAP' xorl %ebx, %ebx # continuation counter movw $E820MAP, %di# point into the whitelist # so we can have the bios @@ -300,13 +301,15 @@ jmpe820: movl $0xe820, %eax# e820, upper word zeroed +movl $SMAP, %edx # do this every time, some + # bioses are forgetful movl $20, %ecx # size of the e820rec pushw %ds # data record. popw %es int $0x15# make the call jc bail820 # fall to e801 if it fails -cmpl $0x534d4150, %eax# check the return is `SMAP' +cmpl $SMAP, %eax # check the return is `SMAP' jne bail820 # fall to e801 if it fails # cmpl $1, 16(%di) # is this usable memory? Again, please copy any comments to me ([EMAIL PROTECTED]), since I'm not subscribed to linux-kernel. -- Marc Joosen Communication Link Design IBM T.J. Watson Research Center Yorktown Heights, NY - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: e820 memory detection fix for ThinkPad
David Weinhall wrote: On Tue, Dec 19, 2000 at 07:16:40PM -0500, Marc Joosen wrote: This is a tiny patch to make the int15/e820 memory mapping work on IBM ThinkPads. Until now, I have had to give lilo a mem= option with one meg If this simple patch solves your problem, great! But in that case, PLEASE add a note telling WHY the assignment is done for every iteration; else some smarthead will probably submit a patch someday in the future along the lines of "assigning this only once makes the loop faster"... Anyhow, good spotting! Thanks for the tip, David. I hope that whoever wants to move that line out of the loop is aware that it is only executed ~10 times :) So I hereby submit a second version of the patch, that includes a link to the documentation and #defines the word SMAP (thanks to David Parsons for that): --- linux/arch/i386/boot/setup.S.origMon Oct 30 17:44:29 2000 +++ linux/arch/i386/boot/setup.S Thu Dec 21 19:37:12 2000 @@ -289,10 +289,11 @@ # a whole bunch of different types, and allows memory holes and # everything. We scan through this memory map and build a list # of the first 32 memory areas, which we return at [E820MAP]. -# +# This is documented at http://www.teleport.com/~acpi/acpihtml/topic245.htm + +#define SMAP 0x534d4150 meme820: -movl $0x534d4150, %edx# ascii `SMAP' xorl %ebx, %ebx # continuation counter movw $E820MAP, %di# point into the whitelist # so we can have the bios @@ -300,13 +301,15 @@ jmpe820: movl $0xe820, %eax# e820, upper word zeroed +movl $SMAP, %edx # do this every time, some + # bioses are forgetful movl $20, %ecx # size of the e820rec pushw %ds # data record. popw %es int $0x15# make the call jc bail820 # fall to e801 if it fails -cmpl $0x534d4150, %eax# check the return is `SMAP' +cmpl $SMAP, %eax # check the return is `SMAP' jne bail820 # fall to e801 if it fails # cmpl $1, 16(%di) # is this usable memory? Again, please copy any comments to me ([EMAIL PROTECTED]), since I'm not subscribed to linux-kernel. -- Marc Joosen Communication Link Design IBM T.J. Watson Research Center Yorktown Heights, NY - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] e820 memory detection fix for ThinkPad
Hi Alan, lkml-readers, This is a tiny patch to make the int15/e820 memory mapping work on IBM ThinkPads. Until now, I have had to give lilo a mem= option with one meg of RAM less than I actually have, so ACPI events don't overwrite any data. The only alternative was to use one of the patches available on http://www.pell.portland.or.us/~orc/Memory/, but these are quite big. I tracked down the problem, at least for the ThinkPad 600X (2645-4EU), to arch/i386/boot/setup.S: apparently the bios doesn't retain the value of register %edx, so after the first entry is read the ascii word `SMAP' is lost and further entries won't be recognized. The solution is simple, just move the assignment 6 lines down so it's inside the loop that is done for every entry. This patch is for 2.4.0-test7..12, but it should work for pre13 kernels and even 2.2 kernels with the memory map backport: --- linux/arch/i386/boot/setup.S.origSat Dec 9 05:56:07 2000 +++ linux/arch/i386/boot/setup.S Sat Dec 9 06:43:03 2000 @@ -292,7 +292,6 @@ # meme820: -movl $0x534d4150, %edx# ascii `SMAP' xorl %ebx, %ebx # continuation counter movw $E820MAP, %di# point into the whitelist # so we can have the bios @@ -300,6 +299,7 @@ jmpe820: movl $0xe820, %eax# e820, upper word zeroed +movl $0x534d4150, %edx# ascii `SMAP' movl $20, %ecx # size of the e820rec pushw %ds # data record. popw %es (I hope it came through properly... it may have been Lotus-Notified.) My ThinkPad now shows this during boot: Linux version 2.4.0-test12 (mjoosen@hexane) (gcc version 2.95.2 19991024 (release)) #2 Sun Dec 10 23:51:04 EST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0bed @ 0010 (usable) BIOS-e820: f000 @ 0bfd (ACPI data) BIOS-e820: 1000 @ 0bfdf000 (ACPI NVS) BIOS-e820: 0002 @ 0bfe (reserved) BIOS-e820: 0002 @ fffe (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009f800 for 4096 bytes. ... and that's without a mem= option to lilo, of course. May I suggest you try this patch in the next 2.[24]-pre kernel? Thanks! BTW: I work for IBM, but I'm not in the PC department (or even ThinkPad development). Unfortunately I won't be able to answer all your IBM-related questions... BTW2: I'm not on the linux-kernel mailing list, so please reply to (remove anti-spam spacing). Regards, -- Marc Joosen Communication Link Design IBM T.J. Watson Research Center Yorktown Heights, NY - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] e820 memory detection fix for ThinkPad
Hi Alan, lkml-readers, This is a tiny patch to make the int15/e820 memory mapping work on IBM ThinkPads. Until now, I have had to give lilo a mem= option with one meg of RAM less than I actually have, so ACPI events don't overwrite any data. The only alternative was to use one of the patches available on http://www.pell.portland.or.us/~orc/Memory/, but these are quite big. I tracked down the problem, at least for the ThinkPad 600X (2645-4EU), to arch/i386/boot/setup.S: apparently the bios doesn't retain the value of register %edx, so after the first entry is read the ascii word `SMAP' is lost and further entries won't be recognized. The solution is simple, just move the assignment 6 lines down so it's inside the loop that is done for every entry. This patch is for 2.4.0-test7..12, but it should work for pre13 kernels and even 2.2 kernels with the memory map backport: --- linux/arch/i386/boot/setup.S.origSat Dec 9 05:56:07 2000 +++ linux/arch/i386/boot/setup.S Sat Dec 9 06:43:03 2000 @@ -292,7 +292,6 @@ # meme820: -movl $0x534d4150, %edx# ascii `SMAP' xorl %ebx, %ebx # continuation counter movw $E820MAP, %di# point into the whitelist # so we can have the bios @@ -300,6 +299,7 @@ jmpe820: movl $0xe820, %eax# e820, upper word zeroed +movl $0x534d4150, %edx# ascii `SMAP' movl $20, %ecx # size of the e820rec pushw %ds # data record. popw %es (I hope it came through properly... it may have been Lotus-Notified.) My ThinkPad now shows this during boot: Linux version 2.4.0-test12 (mjoosen@hexane) (gcc version 2.95.2 19991024 (release)) #2 Sun Dec 10 23:51:04 EST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0bed @ 0010 (usable) BIOS-e820: f000 @ 0bfd (ACPI data) BIOS-e820: 1000 @ 0bfdf000 (ACPI NVS) BIOS-e820: 0002 @ 0bfe (reserved) BIOS-e820: 0002 @ fffe (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009f800 for 4096 bytes. ... and that's without a mem= option to lilo, of course. May I suggest you try this patch in the next 2.[24]-pre kernel? Thanks! BTW: I work for IBM, but I'm not in the PC department (or even ThinkPad development). Unfortunately I won't be able to answer all your IBM-related questions... BTW2: I'm not on the linux-kernel mailing list, so please reply to mjoosen @ us.ibm.com (remove anti-spam spacing). Regards, -- Marc Joosen Communication Link Design IBM T.J. Watson Research Center Yorktown Heights, NY - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops with 2.4.0-test8/Token Ring/Netscape
Hello *, this is a bug report about an Oops I get sometimes with kernel 2.4.0-test8; usually it is triggered by reading newsgroups in Netscape 4.75. I know Netscape is not quite bugfree yet, but at least it shouldn't be allowed to do something this bad. I'm using SuSE 7.0 on a ThinkPad 600X (2645-4EU), with a 500MHz Pentium III, 192M RAM (191M usable -- the int15/e820 memory detection doesn't work) and a Turbo 16/4 PCMCIA Token Ring card. The Oops is generated by a BUG() in ll_rw_blk.c. I'm quite sure this only happens when the network is active. I'll include the output of ksymoops and my kernel configuration. Since I'm not subscribed to the mailing list, I would appreciate a Cc: of any replies. The line in the syslog that precedes the Oops is Sep 14 20:13:21 hexane kernel: kernel BUG at ll_rw_blk.c:711! ksymoops ksymoops 0.7c on i686 2.4.0-test8. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test8/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Sep 14 20:13:21 hexane kernel: invalid operand: Sep 14 20:13:21 hexane kernel: CPU:0 Sep 14 20:13:21 hexane kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Sep 14 20:13:21 hexane kernel: EFLAGS: 00010282 Sep 14 20:13:21 hexane kernel: eax: 001f ebx: c4722720 ecx: cb12ee60 edx: 0001 Sep 14 20:13:21 hexane kernel: esi: c4722720 edi: c02449c0 ebp: 0001 esp: c9793ea8 Sep 14 20:13:21 hexane kernel: ds: 0018 es: 0018 ss: 0018 Sep 14 20:13:21 hexane kernel: Process netscape (pid: 949, stackpage=c9793000) Sep 14 20:13:21 hexane kernel: Stack: c01c3b85 c01c3e22 02c7 c4722720 0001 000c c9793f0c Sep 14 20:13:21 hexane kernel:c02449d8 c02449d0 0008 c0152702 00fe Sep 14 20:13:21 hexane kernel:c01532c1 c02449c0 0001 c4722720 c4722720 0001 c9793f38 Sep 14 20:13:21 hexane kernel: Call Trace: [] [] [] [] [] [] [] Sep 14 20:13:21 hexane kernel:[] [] [] [] [] [] Sep 14 20:13:21 hexane kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 40 90 23 c0 >>EIP; c0152cbd <__make_request+a1/5a4> <= Trace; c01c3b85 Trace; c01c3e22 Trace; c0152702 Trace; c01532c1 Trace; c0153421 Trace; c01239c5 Trace; c0123a64 Trace; c0123ab5 Trace; c012398c Trace; c01477ab Trace; c012d00b Trace; c012de61 Trace; c010a2d7 Code; c0152cbd <__make_request+a1/5a4> <_EIP>: Code; c0152cbd <__make_request+a1/5a4> <= 0: 0f 0b ud2a <= Code; c0152cbf <__make_request+a3/5a4> 2: 83 c4 0c add$0xc,%esp Code; c0152cc2 <__make_request+a6/5a4> 5: 0f b6 46 15 movzbl 0x15(%esi),%eax Code; c0152cc6 <__make_request+aa/5a4> 9: 0f b7 4e 14 movzwl 0x14(%esi),%ecx Code; c0152cca <__make_request+ae/5a4> d: 8b 14 85 40 90 23 c0 mov0xc0239040(,%eax,4),%edx 1 warning issued. Results may not be reliable. end ksymoops The default file locations are ok, so the warning should not be that important. .config # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_M686FXSR=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_BYTES=32 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_MCA is not set
Oops with 2.4.0-test8/Token Ring/Netscape
Hello *, this is a bug report about an Oops I get sometimes with kernel 2.4.0-test8; usually it is triggered by reading newsgroups in Netscape 4.75. I know Netscape is not quite bugfree yet, but at least it shouldn't be allowed to do something this bad. I'm using SuSE 7.0 on a ThinkPad 600X (2645-4EU), with a 500MHz Pentium III, 192M RAM (191M usable -- the int15/e820 memory detection doesn't work) and a Turbo 16/4 PCMCIA Token Ring card. The Oops is generated by a BUG() in ll_rw_blk.c. I'm quite sure this only happens when the network is active. I'll include the output of ksymoops and my kernel configuration. Since I'm not subscribed to the mailing list, I would appreciate a Cc: of any replies. The line in the syslog that precedes the Oops is Sep 14 20:13:21 hexane kernel: kernel BUG at ll_rw_blk.c:711! ksymoops ksymoops 0.7c on i686 2.4.0-test8. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test8/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Sep 14 20:13:21 hexane kernel: invalid operand: Sep 14 20:13:21 hexane kernel: CPU:0 Sep 14 20:13:21 hexane kernel: EIP:0010:[c0152cbd] Using defaults from ksymoops -t elf32-i386 -a i386 Sep 14 20:13:21 hexane kernel: EFLAGS: 00010282 Sep 14 20:13:21 hexane kernel: eax: 001f ebx: c4722720 ecx: cb12ee60 edx: 0001 Sep 14 20:13:21 hexane kernel: esi: c4722720 edi: c02449c0 ebp: 0001 esp: c9793ea8 Sep 14 20:13:21 hexane kernel: ds: 0018 es: 0018 ss: 0018 Sep 14 20:13:21 hexane kernel: Process netscape (pid: 949, stackpage=c9793000) Sep 14 20:13:21 hexane kernel: Stack: c01c3b85 c01c3e22 02c7 c4722720 0001 000c c9793f0c Sep 14 20:13:21 hexane kernel:c02449d8 c02449d0 0008 c0152702 00fe Sep 14 20:13:21 hexane kernel:c01532c1 c02449c0 0001 c4722720 c4722720 0001 c9793f38 Sep 14 20:13:21 hexane kernel: Call Trace: [c01c3b85] [c01c3e22] [c0152702] [c01532c1] [c0153421] [c01239c5] [c0123a64] Sep 14 20:13:21 hexane kernel:[c0123ab5] [c012398c] [c01477ab] [c012d00b] [c012de61] [c010a2d7] Sep 14 20:13:21 hexane kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 40 90 23 c0 EIP; c0152cbd __make_request+a1/5a4 = Trace; c01c3b85 tvecs+a3dd/bed8 Trace; c01c3e22 tvecs+a67a/bed8 Trace; c0152702 blk_get_queue+32/40 Trace; c01532c1 generic_make_request+101/110 Trace; c0153421 ll_rw_block+151/1c0 Trace; c01239c5 writeout_one_page+39/50 Trace; c0123a64 do_buffer_fdatasync+48/7c Trace; c0123ab5 generic_buffer_fdatasync+1d/38 Trace; c012398c writeout_one_page+0/50 Trace; c01477ab ext2_sync_file+2f/a4 Trace; c012d00b sys_write+8b/a0 Trace; c012de61 sys_fsync+49/68 Trace; c010a2d7 system_call+33/38 Code; c0152cbd __make_request+a1/5a4 _EIP: Code; c0152cbd __make_request+a1/5a4 = 0: 0f 0b ud2a = Code; c0152cbf __make_request+a3/5a4 2: 83 c4 0c add$0xc,%esp Code; c0152cc2 __make_request+a6/5a4 5: 0f b6 46 15 movzbl 0x15(%esi),%eax Code; c0152cc6 __make_request+aa/5a4 9: 0f b7 4e 14 movzwl 0x14(%esi),%ecx Code; c0152cca __make_request+ae/5a4 d: 8b 14 85 40 90 23 c0 mov0xc0239040(,%eax,4),%edx 1 warning issued. Results may not be reliable. end ksymoops The default file locations are ok, so the warning should not be that important. .config # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_M686FXSR=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_BYTES=32 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G
