Re: Unable to handle kernel paging request (2.4.4-ac6)
.Jorge Nerin wrote: > Hello, today I got an Oops in 2.4.4-ac6, X crashed and gdm restarted, > my system is a dual 2x200MMX, 96Mb, Voodoo 3 2000pci XFree 4.0.3, no drm. > In reply to myself I must add this series of Oopses and invalid operands to my mail, also on 2.4.4.-ac6. The system was runing at the time I did the trace, so all symbols should be ok. ksymoops 2.3.4 on i586 2.4.4-ac6. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.4-ac6/ (default) -m /boot/System.map-2.4.4-ac6 (specified) cpu: 0, clocks: 668184, slice: 222728 cpu: 1, clocks: 668184, slice: 222728 8139too Fast Ethernet driver 0.9.17 Unable to handle kernel NULL pointer dereference at virtual address 0157 c0144b69 Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: c24b7f54 ebx: 0143 ecx: c24b7f54 edx: c5997884 esi: c57df000 edi: c57df008 ebp: esp: c24b7f28 ds: 0018 es: 0018 ss: 0018 Process enlightenment (pid: 1091, stackpage=c24b7000) Stack: 0005 c0144f2d c24b7f54 c24b7f54 0304 c24b6000 0005 c57df000 0001 bfffe684 c5997898 0005 c01452b9 0005 c24b7f90 c24b7f8c bfffdd88 c0194780 0004 Call Trace: [] [] [] [] [] Code: 8b 43 14 8d 53 04 e8 2c f8 fc ff 8b 03 e8 c5 11 ff ff 39 fb >>EIP; c0144b69<= Trace; c0144f2d Trace; c01452b9 Trace; c0194780 Trace; c01444ba Trace; c0106e57 Code; c0144b69 <_EIP>: Code; c0144b69<= 0: 8b 43 14 mov0x14(%ebx),%eax <= Code; c0144b6c 3: 8d 53 04 lea0x4(%ebx),%edx Code; c0144b6f 6: e8 2c f8 fc ffcall fffcf837 <_EIP+0xfffcf837> c01143a0 Code; c0144b74 b: 8b 03 mov(%ebx),%eax Code; c0144b76 d: e8 c5 11 ff ffcall 11d7 <_EIP+0x11d7> c0135d40 Code; c0144b7b 12: 39 fb cmp%edi,%ebx <1>Unable to handle kernel paging request at virtual address 2f323433 c01135e4 Oops: CPU:1 EIP:0010:[] EFLAGS: 00210002 eax: c184a208 ebx: 752f002f ecx: 2f323433 edx: 0001 esi: c23754a0 edi: c57df024 ebp: c28bdecc esp: c28bdeac ds: 0018 es: 0018 ss: 0018 Process gnome-session (pid: 1056, stackpage=c28bd000) Stack: c184a20c 00200282 0001 c184a208 c184a208 c23754a0 c2375100 c5f6f940 c0197003 c23754a0 0001 c01d6ca4 c23754a0 0001 c2879ac0 0009 c3af5000 c2651260 00200296 c17ecacc c5ffaac0 c17ec9c0 c1727f20 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 8b 01 85 45 ec 74 ec 31 c0 9c 5e fa f0 fe 0d 00 b4 26 c0 0f >>EIP; c01135e4 <__wake_up+44/d0> <= Trace; c0197003 Trace; c01d6ca4 Trace; c01d703f Trace; c01942d0 Trace; c0194840 Trace; c0135d77 Trace; c0134c2e Trace; c011856d Trace; c0118d7d Trace; c0106e57 Code; c01135e4 <__wake_up+44/d0> <_EIP>: Code; c01135e4 <__wake_up+44/d0> <= 0: 8b 01 mov(%ecx),%eax <= Code; c01135e6 <__wake_up+46/d0> 2: 85 45 ec test %eax,0xffec(%ebp) Code; c01135e9 <__wake_up+49/d0> 5: 74 ec je fff3 <_EIP+0xfff3> c01135d7 <__wake_up+37/d0> Code; c01135eb <__wake_up+4b/d0> 7: 31 c0 xor%eax,%eax Code; c01135ed <__wake_up+4d/d0> 9: 9cpushf Code; c01135ee <__wake_up+4e/d0> a: 5epop%esi Code; c01135ef <__wake_up+4f/d0> b: facli Code; c01135f0 <__wake_up+50/d0> c: f0 fe 0d 00 b4 26 c0 lock decb 0xc026b400 Code; c01135f7 <__wake_up+57/d0> 13: 0f 00 00 sldt (%eax) invalid operand: CPU:1 EIP:0010:[] EFLAGS: 00013282 eax: 0020 ebx: c115ce2c ecx: c021f400 edx: 3b84 esi: 5000 edi: c110 ebp: esp: c3919e2c ds: 0018 es: 0018 ss: 0018 Process X (pid: 3730, stackpage=c3919000) Stack: c01f0cba 00cb 4217 3282 c02207f8 c02207f8 c02209d0 0005 c012f49e 0001 c02209cc 0025 c301dc20 c5dda8c0 c37b9e7c c01248c1 c301dc20 c5dda8c0 0001 c37b9e7c c0124970 c5dda8c0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5f 5d 89 d8 eb 1b 47 83 c6 0c 83 ff 09 0f 86 a0 fd ff >>EIP; c012f35b<= Trace; c012f49e <__alloc_pages+6e/260> Trace; c01248c1 Trace; c0124970 Trace; c0124a99 Trace; c012784f Trace; c0112370 Trace; c0112517 Trace; c01259d4 Trace; c018868b Trace; c011dc46 Trace; c0125ce4 Trace; c0124e1d Trace; c0112370 Trace; c0106fb4 Code; c012f35b <_EIP>: Code; c012f35b<= 0: 0f 0b
Re: Unable to handle kernel paging request (2.4.4-ac6)
.Jorge Nerin wrote: Hello, today I got an Oops in 2.4.4-ac6, X crashed and gdm restarted, my system is a dual 2x200MMX, 96Mb, Voodoo 3 2000pci XFree 4.0.3, no drm. In reply to myself I must add this series of Oopses and invalid operands to my mail, also on 2.4.4.-ac6. The system was runing at the time I did the trace, so all symbols should be ok. ksymoops 2.3.4 on i586 2.4.4-ac6. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.4-ac6/ (default) -m /boot/System.map-2.4.4-ac6 (specified) cpu: 0, clocks: 668184, slice: 222728 cpu: 1, clocks: 668184, slice: 222728 8139too Fast Ethernet driver 0.9.17 Unable to handle kernel NULL pointer dereference at virtual address 0157 c0144b69 Oops: CPU:0 EIP:0010:[c0144b69] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: c24b7f54 ebx: 0143 ecx: c24b7f54 edx: c5997884 esi: c57df000 edi: c57df008 ebp: esp: c24b7f28 ds: 0018 es: 0018 ss: 0018 Process enlightenment (pid: 1091, stackpage=c24b7000) Stack: 0005 c0144f2d c24b7f54 c24b7f54 0304 c24b6000 0005 c57df000 0001 bfffe684 c5997898 0005 c01452b9 0005 c24b7f90 c24b7f8c bfffdd88 c0194780 0004 Call Trace: [c0144f2d] [c01452b9] [c0194780] [c01444ba] [c0106e57] Code: 8b 43 14 8d 53 04 e8 2c f8 fc ff 8b 03 e8 c5 11 ff ff 39 fb EIP; c0144b69 poll_freewait+19/50 = Trace; c0144f2d do_select+22d/250 Trace; c01452b9 sys_select+339/490 Trace; c0194780 sock_ioctl+50/80 Trace; c01444ba sys_ioctl+28a/2a0 Trace; c0106e57 system_call+37/40 Code; c0144b69 poll_freewait+19/50 _EIP: Code; c0144b69 poll_freewait+19/50 = 0: 8b 43 14 mov0x14(%ebx),%eax = Code; c0144b6c poll_freewait+1c/50 3: 8d 53 04 lea0x4(%ebx),%edx Code; c0144b6f poll_freewait+1f/50 6: e8 2c f8 fc ffcall fffcf837 _EIP+0xfffcf837 c01143a0 remove_wait_queue+0/20 Code; c0144b74 poll_freewait+24/50 b: 8b 03 mov(%ebx),%eax Code; c0144b76 poll_freewait+26/50 d: e8 c5 11 ff ffcall 11d7 _EIP+0x11d7 c0135d40 fput+0/e0 Code; c0144b7b poll_freewait+2b/50 12: 39 fb cmp%edi,%ebx 1Unable to handle kernel paging request at virtual address 2f323433 c01135e4 Oops: CPU:1 EIP:0010:[c01135e4] EFLAGS: 00210002 eax: c184a208 ebx: 752f002f ecx: 2f323433 edx: 0001 esi: c23754a0 edi: c57df024 ebp: c28bdecc esp: c28bdeac ds: 0018 es: 0018 ss: 0018 Process gnome-session (pid: 1056, stackpage=c28bd000) Stack: c184a20c 00200282 0001 c184a208 c184a208 c23754a0 c2375100 c5f6f940 c0197003 c23754a0 0001 c01d6ca4 c23754a0 0001 c2879ac0 0009 c3af5000 c2651260 00200296 c17ecacc c5ffaac0 c17ec9c0 c1727f20 Call Trace: [c0197003] [c01d6ca4] [c01d703f] [c01942d0] [c0194840] [c0135d77] [c0134c2e] [c011856d] [c0118d7d] [c0106e57] Code: 8b 01 85 45 ec 74 ec 31 c0 9c 5e fa f0 fe 0d 00 b4 26 c0 0f EIP; c01135e4 __wake_up+44/d0 = Trace; c0197003 sock_def_wakeup+33/40 Trace; c01d6ca4 unix_release_sock+154/280 Trace; c01d703f unix_release+1f/30 Trace; c01942d0 sock_release+10/60 Trace; c0194840 sock_close+30/40 Trace; c0135d77 fput+37/e0 Trace; c0134c2e filp_close+9e/b0 Trace; c011856d put_files_struct+4d/d0 Trace; c0118d7d do_exit+12d/290 Trace; c0106e57 system_call+37/40 Code; c01135e4 __wake_up+44/d0 _EIP: Code; c01135e4 __wake_up+44/d0 = 0: 8b 01 mov(%ecx),%eax = Code; c01135e6 __wake_up+46/d0 2: 85 45 ec test %eax,0xffec(%ebp) Code; c01135e9 __wake_up+49/d0 5: 74 ec je fff3 _EIP+0xfff3 c01135d7 __wake_up+37/d0 Code; c01135eb __wake_up+4b/d0 7: 31 c0 xor%eax,%eax Code; c01135ed __wake_up+4d/d0 9: 9cpushf Code; c01135ee __wake_up+4e/d0 a: 5epop%esi Code; c01135ef __wake_up+4f/d0 b: facli Code; c01135f0 __wake_up+50/d0 c: f0 fe 0d 00 b4 26 c0 lock decb 0xc026b400 Code; c01135f7 __wake_up+57/d0 13: 0f 00 00 sldt (%eax) invalid operand: CPU:1 EIP:0010:[c012f35b] EFLAGS: 00013282 eax: 0020 ebx: c115ce2c ecx: c021f400 edx: 3b84 esi: 5000 edi: c110 ebp: esp: c3919e2c ds: 0018 es: 0018 ss: 0018 Process X (pid: 3730, stackpage=c3919000) Stack: c01f0cba 00cb 4217 3282 c02207f8 c02207f8 c02209d0 0005 c012f49e 0001 c02209cc 0025 c301dc20 c5dda8c0 c37b9e7c c01248c1 c301dc20 c5dda8c0 0001 c37b9e7c c0124970 c5dda8c0 Call Trace: [c012f49e] [c01248c1] [c0124970] [c0124a99] [c012784f] [c0112370] [c0112517] [c01259d4] [c018868b] [c011dc46
Re: Memory management issues with 2.4.4
Marcelo Tosatti wrote: > > On Wed, 2 May 2001, Jorge Nerin wrote: > >> Short version: >> Under very heavy thrashing (about four hours) the system either lockups >> or OOM handler kills a task even when there is swap space left. > > > First of all, please try to reproduce the problem with 2.4.5-pre1. > > If it still happens with pre1, please show us the output of "cat > /proc/slabinfo" when the kernel is about to trigger the OOM killer. > > Thanks. > Well, as I had said this morning I have feed the Oops to ksymoops, note that I may have mirtyped something, but anyway here is the output of ksymoops: ksymoops 2.3.4 on i586 2.4.5-pre1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-pre1/ (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. Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry invalid operand: CPU: 1 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010096 eax: 001b ebx: ecx: 0001 edx: 0001 esi: c021b960 edi: c5fe2000 ebp: c5fe3ce0 esp: c5fe3c88 Stack: c01e89a5 c01c8af6 02c5 c021b960 c021b954 0001 0020 00cc c02961c0 0120 c012ca08 c5fe2000 c216960 c21b954 c5fe2000 0080 0001 c5fe2000 0001 0001 c12da64 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 8d 65 b4 5b 5f 89 ec 5d c3 55 89 e5 83 ec 18 57 56 >>EIP; 0c0123c4 Before first symbol <= Trace; c012ca08 Trace; c012da64 <__alloc_pages+16c/2c0> Trace; c012dbcc <__get_free_pages+14/20> Trace; c0113bbb Trace; c01058c9 Trace; c0106d07 Trace; c010e568 Trace; c01054ea Trace; c010e591 Trace; c010e568 Trace; c01746de Trace; c0172dfd Trace; c0173fcc Trace; c017405c Trace; c0108516 Trace; c0108709 Trace; c0106de0 Trace; c010fc60 Trace; c0129e78 Trace; c0129c78 Trace; c0129e52 Trace; c0129e78 Trace; c0129f56 Trace; c0129e78 Trace; c0129f83 <__kmem_cache_shrink+b/6c> Trace; c0129a29 Trace; c01471a4 Trace; c012cc9b Trace; c012cd2b Trace; c0105000 Trace; c01054f3 Code; 0c0123c4 Before first symbol <_EIP>: Code; 0c0123c4 Before first symbol <= 0: 0f 0b ud2a <= Code; 0c0123c6 Before first symbol 2: 8d 65 b4 lea0xffb4(%ebp),%esp Code; 0c0123c9 Before first symbol 5: 5bpop%ebx Code; 0c0123ca Before first symbol 6: 5fpop%edi Code; 0c0123cb Before first symbol 7: 89 ec mov%ebp,%esp Code; 0c0123cd Before first symbol 9: 5dpop%ebp Code; 0c0123ce Before first symbol a: c3ret Code; 0c0123cf Before first symbol b: 55push %ebp Code; 0c0123d0 Before first symbol c: 89 e5 mov%esp,%ebp Code; 0c0123d2 Before first symbol e: 83 ec 18 sub$0x18,%esp Code; 0c0123d5 Before first symbol 11: 57push %edi Code; 0c0123d6 Before first symbol 12: 56push %esi Kernel panic Aiee killing interrupt handler 2 warnings issued. Results may not be reliable. As I said I have tried to no make errors, but I copied it at 7 in the morning, so who knows ... ;-) -- Jorge Nerin <[EMAIL PROTECTED]> - 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: Memory management issues with 2.4.4
Marcelo Tosatti wrote: On Wed, 2 May 2001, Jorge Nerin wrote: Short version: Under very heavy thrashing (about four hours) the system either lockups or OOM handler kills a task even when there is swap space left. First of all, please try to reproduce the problem with 2.4.5-pre1. If it still happens with pre1, please show us the output of cat /proc/slabinfo when the kernel is about to trigger the OOM killer. Thanks. Well, as I had said this morning I have feed the Oops to ksymoops, note that I may have mirtyped something, but anyway here is the output of ksymoops: ksymoops 2.3.4 on i586 2.4.5-pre1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-pre1/ (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. Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry invalid operand: CPU: 1 EIP: 0010:[c0123c4] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010096 eax: 001b ebx: ecx: 0001 edx: 0001 esi: c021b960 edi: c5fe2000 ebp: c5fe3ce0 esp: c5fe3c88 Stack: c01e89a5 c01c8af6 02c5 c021b960 c021b954 0001 0020 00cc c02961c0 0120 c012ca08 c5fe2000 c216960 c21b954 c5fe2000 0080 0001 c5fe2000 0001 0001 c12da64 Call Trace: [c012ca08] [c012da64] [c012dbcc] [c0113bbb] [c01058c9] [c0106d07] [c010e568] [c01054ea] [c010e591] [c010e568] [c01746de] [c0172dfd] [c0173fcc] [c017405c] [c0108516] [c0108709] [c0106de0] [c010fc60] [c0129e78] [c0129c78] [c0129e52] [c0129e78] [c0129f56] [c0129e78] [c0129f83] [c0129a29] [c01471a4] [c012cc9b] [c012cd2b] [c0105000] [c01054f3] Code: 0f 0b 8d 65 b4 5b 5f 89 ec 5d c3 55 89 e5 83 ec 18 57 56 EIP; 0c0123c4 Before first symbol = Trace; c012ca08 free_shortage+1c/100 Trace; c012da64 __alloc_pages+16c/2c0 Trace; c012dbcc __get_free_pages+14/20 Trace; c0113bbb do_fork+93/770 Trace; c01058c9 sys_clone+1d/24 Trace; c0106d07 system_call+37/40 Trace; c010e568 apm_magic+0/8 Trace; c01054ea kernel_thread+1a/30 Trace; c010e591 apm_power_off+21/3c Trace; c010e568 apm_magic+0/8 Trace; c01746de handle_sysrq+de/230 Trace; c0172dfd handle_scancode+1bd/318 Trace; c0173fcc handle_kbd_event+130/1a4 Trace; c017405c keyboard_interrupt+1c/28 Trace; c0108516 handle_IRQ_event+52/7c Trace; c0108709 do_IRQ+99/ec Trace; c0106de0 ret_from_intr+0/20 Trace; c010fc60 smp_call_function+8c/c0 Trace; c0129e78 do_ccupdate_local+0/40 Trace; c0129c78 kmem_cache_create+220/3e0 Trace; c0129e52 smp_call_function_all_cpus+1a/40 Trace; c0129e78 do_ccupdate_local+0/40 Trace; c0129f56 drain_cpu_caches+9e/c0 Trace; c0129e78 do_ccupdate_local+0/40 Trace; c0129f83 __kmem_cache_shrink+b/6c Trace; c0129a29 kmem_slab_destroy+79/a8 Trace; c01471a4 shrink_dcache_memory+2c/30 Trace; c012cc9b do_try_to_free_pages+5f/7c Trace; c012cd2b kswapd+73/110 Trace; c0105000 init+0/1b0 Trace; c01054f3 kernel_thread+23/30 Code; 0c0123c4 Before first symbol _EIP: Code; 0c0123c4 Before first symbol = 0: 0f 0b ud2a = Code; 0c0123c6 Before first symbol 2: 8d 65 b4 lea0xffb4(%ebp),%esp Code; 0c0123c9 Before first symbol 5: 5bpop%ebx Code; 0c0123ca Before first symbol 6: 5fpop%edi Code; 0c0123cb Before first symbol 7: 89 ec mov%ebp,%esp Code; 0c0123cd Before first symbol 9: 5dpop%ebp Code; 0c0123ce Before first symbol a: c3ret Code; 0c0123cf Before first symbol b: 55push %ebp Code; 0c0123d0 Before first symbol c: 89 e5 mov%esp,%ebp Code; 0c0123d2 Before first symbol e: 83 ec 18 sub$0x18,%esp Code; 0c0123d5 Before first symbol 11: 57push %edi Code; 0c0123d6 Before first symbol 12: 56push %esi Kernel panic Aiee killing interrupt handler 2 warnings issued. Results may not be reliable. As I said I have tried to no make errors, but I copied it at 7 in the morning, so who knows ... ;-) -- Jorge Nerin [EMAIL PROTECTED] - 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
Memory management issues with 2.4.4
Short version: Under very heavy thrashing (about four hours) the system either lockups or OOM handler kills a task even when there is swap space left. Long version: My system is a dual 2x200MMX in a Gigabyte 586DX with 96Mb and 226Mb of swap this way: [root@quartz ~]# swapon -s FilenameTypeSizeUsedPriority /dev/hda7 partition 96348 64561 /dev/hdc6 partition 130276 64601 Well, I have tried to compile Mozilla 0.8.1 since the day it came out, but I always lockup in the same place, wich it's begining to be a bit frustrating ;-) The problem is that compiling the file content/base/src/nsStyleContext.o makes cc1plus grow up to a size of 141M, at this point the system is in heavy thrashing, kswapd is using about 7-12% of CPU time and cc1plus is using 8-14%. If I use a SMP kernel the system always ends up frozen, some times after about almost one day of uptime and compiling since booting, and another times it gets frozen in much less time, three or four hours. If I use a non SMP kernel the system doesn't lokup but after some hours, it varies between 6-8h, the cc1plus procces get a kill signal by OOM killer, althought there is plenty of swap space left ((96Mb RAM + 226Mb swap) - (140Mb - tiny amount used by the system) = plenty ;-). For this tries I have left the system in single user, so no cron jobs, no network trafic, no etc... I suspect there is a race in the swap handling in SMP, and that the OOM doesn't take into account the swap space left sometimes. I don't know what to try next, suggestions? -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Memory management issues with 2.4.4
Short version: Under very heavy thrashing (about four hours) the system either lockups or OOM handler kills a task even when there is swap space left. Long version: My system is a dual 2x200MMX in a Gigabyte 586DX with 96Mb and 226Mb of swap this way: [root@quartz ~]# swapon -s FilenameTypeSizeUsedPriority /dev/hda7 partition 96348 64561 /dev/hdc6 partition 130276 64601 Well, I have tried to compile Mozilla 0.8.1 since the day it came out, but I always lockup in the same place, wich it's begining to be a bit frustrating ;-) The problem is that compiling the file content/base/src/nsStyleContext.o makes cc1plus grow up to a size of 141M, at this point the system is in heavy thrashing, kswapd is using about 7-12% of CPU time and cc1plus is using 8-14%. If I use a SMP kernel the system always ends up frozen, some times after about almost one day of uptime and compiling since booting, and another times it gets frozen in much less time, three or four hours. If I use a non SMP kernel the system doesn't lokup but after some hours, it varies between 6-8h, the cc1plus procces get a kill signal by OOM killer, althought there is plenty of swap space left ((96Mb RAM + 226Mb swap) - (140Mb - tiny amount used by the system) = plenty ;-). For this tries I have left the system in single user, so no cron jobs, no network trafic, no etc... I suspect there is a race in the swap handling in SMP, and that the OOM doesn't take into account the swap space left sometimes. I don't know what to try next, suggestions? -- Jorge Nerin [EMAIL PROTECTED] - 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: how does linux support domino?
Xiong Zhao wrote: > hello.on linux we will see a new domino server process/thread is created for each > client.how does linux do this?does it use pthread?using fork or clone or someway > else?what's the common way of linux to support apps like lotus domino that will > have lots of concurrent users which are served by seperate server process/thread? > regards > > james Well, in Linux there is no separate concept of threads, so each thread is a separate process with it's own PID and the PPID of the main thread. In fact pthread_create() sits just on top of clone(). The way each program handles multiple conections is up to the program, for example apache 1.3 and below does a fork(), mozilla does a pthread_create(), BOA does a select() in only one process, and apache 2.0 and up does both a fork() and pthread_create(). -- Jorge Nerin <[EMAIL PROTECTED]> - 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: how does linux support domino?
Xiong Zhao wrote: hello.on linux we will see a new domino server process/thread is created for each client.how does linux do this?does it use pthread?using fork or clone or someway else?what's the common way of linux to support apps like lotus domino that will have lots of concurrent users which are served by seperate server process/thread? regards james Well, in Linux there is no separate concept of threads, so each thread is a separate process with it's own PID and the PPID of the main thread. In fact pthread_create() sits just on top of clone(). The way each program handles multiple conections is up to the program, for example apache 1.3 and below does a fork(), mozilla does a pthread_create(), BOA does a select() in only one process, and apache 2.0 and up does both a fork() and pthread_create(). -- Jorge Nerin [EMAIL PROTECTED] - 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: Win keys not working in console (2.4.x)
Guest section DW wrote: > On Tue, Mar 27, 2001 at 11:33:34PM +0200, Jorge Nerin wrote: > > >> Hello, good work with 2.4.x, but I miss one thing. in early 2.3.x the MS >> keys, you know, two flags and one "properties" key worked as navigation >> keys in the console. >> >> The flags get you to the "left" or "rigth" virtual console, and the >> "properties" key put you on the last console you where before. >> >> This was very useful when working in the console, I use the console >> sometimes, and I miss these feature. > > > (i) Find out what key codes these keys generate. > Vaguely I seem to recall that I made these keys produce 125, 126, 127. > (the test command is "showkey") > > (ii) Use loadkeys to assign functions to keys. > For example, > % loadkeys > keycode 125 = Incr_Console > keycode 126 = Decr_Console > keycode 127 = Last_Console > ^D > should give you the desired behaviour. > Perhaps you lost some settings during an upgrade. > > See loadkeys(1) and keytables(5). Oh, thanks, as you say I should have lost it in an upgrade, don't know how. I thougth it was a kernel issue, sorry. :( Thanks. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Win keys not working in console (2.4.x)
Hello, good work with 2.4.x, but I miss one thing. in early 2.3.x the MS keys, you know, two flags and one "properties" key worked as navigation keys in the console. The flags get you to the "left" or "rigth" virtual console, and the "properties" key put you on the last console you where before. This was very useful when working in the console, I use the console sometimes, and I miss these feature. Is there a plan to put back these keys to work, or there was a problem of some kind and this feature got dropped? -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Voodoo 3 pci issues
Hello, I'm using 2.4.2-ac24, Xfree86 4.0.2 + 4.0.3 upgrade, Glide_V3-2.60-16 & Glide_V3-DRI-3.10-6, and tdfx framebuffer. My system is a 2x200MMX on a Gigabyte 586DX with 96Mb, a Voodoo3 2000 pci and a bt848 tv card. I have the card working ok, except for a few nonstopers. - I cannot use the 3D part of my card with XFree 4.x (it worked with 3.3.x) it doesn't matter whether I use or not tdfx.o or whether or not I put a LoadModule dri in the XF86Config. Only root can run the test3Dfx program, and when the program finish X is restored but freezed, so I have to do a SysRQ-K to kill it. - If I try to use fbtv (watch tv in FB) the system hangs, the program starts, and I can see the tv on the screen, but the system is freezed. - If I put a LoadModule dri in the XF86Config, I cannot use the virtual consoles. If I go to a text console (tdfx frame buffer at 100x37) I see the contents of the text console (issue and login prompt), but I see a line near the top of the console of random pixels of one pixel that paints pixels from left to rigth from top to botttom, and I cannont see what I'm typing. I can ony come back to X. When I'm on that VT if I switch to another VT I still see the contents of the first VT that I switched from X. Thanks for your patience. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Win keys not working in console (2.4.x)
Hello, good work with 2.4.x, but I miss one thing. in early 2.3.x the MS keys, you know, two flags and one "properties" key worked as navigation keys in the console. The flags get you to the "left" or "rigth" virtual console, and the "properties" key put you on the last console you where before. This was very useful when working in the console, I use the console sometimes, and I miss these feature. Is there a plan to put back these keys to work, or there was a problem of some kind and this feature got dropped? -- Jorge Nerin [EMAIL PROTECTED] - 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/
Voodoo 3 pci issues
Hello, I'm using 2.4.2-ac24, Xfree86 4.0.2 + 4.0.3 upgrade, Glide_V3-2.60-16 Glide_V3-DRI-3.10-6, and tdfx framebuffer. My system is a 2x200MMX on a Gigabyte 586DX with 96Mb, a Voodoo3 2000 pci and a bt848 tv card. I have the card working ok, except for a few nonstopers. - I cannot use the 3D part of my card with XFree 4.x (it worked with 3.3.x) it doesn't matter whether I use or not tdfx.o or whether or not I put a LoadModule dri in the XF86Config. Only root can run the test3Dfx program, and when the program finish X is restored but freezed, so I have to do a SysRQ-K to kill it. - If I try to use fbtv (watch tv in FB) the system hangs, the program starts, and I can see the tv on the screen, but the system is freezed. - If I put a LoadModule dri in the XF86Config, I cannot use the virtual consoles. If I go to a text console (tdfx frame buffer at 100x37) I see the contents of the text console (issue and login prompt), but I see a line near the top of the console of random pixels of one pixel that paints pixels from left to rigth from top to botttom, and I cannont see what I'm typing. I can ony come back to X. When I'm on that VT if I switch to another VT I still see the contents of the first VT that I switched from X. Thanks for your patience. -- Jorge Nerin [EMAIL PROTECTED] - 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: Win keys not working in console (2.4.x)
Guest section DW wrote: On Tue, Mar 27, 2001 at 11:33:34PM +0200, Jorge Nerin wrote: Hello, good work with 2.4.x, but I miss one thing. in early 2.3.x the MS keys, you know, two flags and one "properties" key worked as navigation keys in the console. The flags get you to the "left" or "rigth" virtual console, and the "properties" key put you on the last console you where before. This was very useful when working in the console, I use the console sometimes, and I miss these feature. (i) Find out what key codes these keys generate. Vaguely I seem to recall that I made these keys produce 125, 126, 127. (the test command is "showkey") (ii) Use loadkeys to assign functions to keys. For example, % loadkeys keycode 125 = Incr_Console keycode 126 = Decr_Console keycode 127 = Last_Console ^D should give you the desired behaviour. Perhaps you lost some settings during an upgrade. See loadkeys(1) and keytables(5). Oh, thanks, as you say I should have lost it in an upgrade, don't know how. I thougth it was a kernel issue, sorry. :( Thanks. -- Jorge Nerin [EMAIL PROTECTED] - 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/
kernel BUG at slab.c:1542! (2.4.1-pre9)
Hello, this is perfectly reproductable, fresh RH7.0 kernel 2.4.1-pre9 compiled with kgcc, and the same bug in pre1, pre4 & pre9. I only need to run xfontsel and the xfs dies, every time, prefectly reproductable. Using XFree86-xfs-4.0.1-1, and this XFree packages: XFree86-4.0.1-1 XFree86-tools-4.0.1-1 XFree86-xdm-4.0.1-1 XFree86-libs-4.0.1-1 XFree86-xfs-4.0.1-1 XFree86-75dpi-fonts-4.0.1-1 XFree86-SVGA-3.3.6-33 XFree86-twm-4.0.1-1 XFree86-VGA16-3.3.6-33 XFree86-Xnest-4.0.1-1 XFree86-devel-4.0.1-1 XFree86-V4L-4.0.1-1 Pentium 2x200mmx 96mb ram, voodoo 3 200pci, more info as requested, and also some patches are welcome. ksymoops 2.3.4 on i586 2.4.1-pre9. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1-pre9/ (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. activating NMI Watchdog ... done. cpu: 0, clocks: 668150, slice: 222716 cpu: 1, clocks: 668150, slice: 222716 8139too Fast Ethernet driver 0.9.13 loaded invalid operand: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010292 eax: 001b ebx: c27cc680 ecx: 0008 edx: c5802ca0 esi: 0003 edi: c431 ebp: c431 esp: c4311de4 ds: 0018 es: 0018 ss: 0018 Process xfs (pid: 909, stackpage=c4311000) Stack: c01e97a5 c01e9825 0606 c27cc680 0003 c431 c431 c0111d3b c5fe3f0c 01a8 c0196cfa 0003fff4 0003 c5c96c20 c431 0ff0 0206 c01963fe 0003fff0 0003 c2f8a164 0003ffec c01d1550 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8d 74 26 00 31 c0 5b 5e 5f 5d 83 c4 0c c3 >>EIP; c012c056<= Trace; c0111d3b Trace; c0196cfa Trace; c01963fe Trace; c01d1550 Trace; c01d167e Trace; c01d1550 Trace; c0193fad Trace; c01d1550 Trace; c0194260 Trace; c01942e2 Trace; c0134763 Trace; c01348c9 Trace; c0108fc7 Code; c012c056 <_EIP>: Code; c012c056<= 0: 0f 0b ud2a <= Code; c012c058 2: 83 c4 0c add$0xc,%esp Code; c012c05b 5: 90nop Code; c012c05c 6: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c012c060 a: 31 c0 xor%eax,%eax Code; c012c062 c: 5bpop%ebx Code; c012c063 d: 5epop%esi Code; c012c064 e: 5fpop%edi Code; c012c065 f: 5dpop%ebp Code; c012c066 10: 83 c4 0c add$0xc,%esp Code; c012c069 13: c3ret 1 warning issued. Results may not be reliable. kernel BUG at slab.c:1542! invalid operand: CPU:1 EIP:0010:[kmalloc+274/296] EFLAGS: 00010292 eax: 001b ebx: c27cc680 ecx: 0008 edx: c5802ca0 esi: 0003 edi: c431 ebp: c431 esp: c4311de4 ds: 0018 es: 0018 ss: 0018 Process xfs (pid: 909, stackpage=c4311000) Stack: c01e97a5 c01e9825 0606 c27cc680 0003 c431 c431 c0111d3b c5fe3f0c 01a8 c0196cfa 0003fff4 0003 c5c96c20 c431 0ff0 0206 c01963fe 0003fff0 0003 c2f8a164 0003ffec c01d1550 Call Trace: [smp_call_function_interrupt+31/52] [alloc_skb+258/416] [sock_alloc_send_skb+114/300] [unix_stream_sendmsg+0/784] [unix_stream_sendmsg+302/784] [unix_stream_sendmsg+0/784] [sock_sendmsg+129/164] [unix_stream_sendmsg+0/784] [sock_readv_writev+140/152] [sock_writev+54/64] [do_readv_writev+387/596] [sys_writev+65/84] [system_call+55/64] Code: 0f 0b 83 c4 0c 90 8d 74 26 00 31 c0 5b 5e 5f 5d 83 c4 0c c3 -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
kernel BUG at slab.c:1542! (2.4.1-pre9)
Hello, this is perfectly reproductable, fresh RH7.0 kernel 2.4.1-pre9 compiled with kgcc, and the same bug in pre1, pre4 pre9. I only need to run xfontsel and the xfs dies, every time, prefectly reproductable. Using XFree86-xfs-4.0.1-1, and this XFree packages: XFree86-4.0.1-1 XFree86-tools-4.0.1-1 XFree86-xdm-4.0.1-1 XFree86-libs-4.0.1-1 XFree86-xfs-4.0.1-1 XFree86-75dpi-fonts-4.0.1-1 XFree86-SVGA-3.3.6-33 XFree86-twm-4.0.1-1 XFree86-VGA16-3.3.6-33 XFree86-Xnest-4.0.1-1 XFree86-devel-4.0.1-1 XFree86-V4L-4.0.1-1 Pentium 2x200mmx 96mb ram, voodoo 3 200pci, more info as requested, and also some patches are welcome. ksymoops 2.3.4 on i586 2.4.1-pre9. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1-pre9/ (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. activating NMI Watchdog ... done. cpu: 0, clocks: 668150, slice: 222716 cpu: 1, clocks: 668150, slice: 222716 8139too Fast Ethernet driver 0.9.13 loaded invalid operand: CPU:1 EIP:0010:[c012c056] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010292 eax: 001b ebx: c27cc680 ecx: 0008 edx: c5802ca0 esi: 0003 edi: c431 ebp: c431 esp: c4311de4 ds: 0018 es: 0018 ss: 0018 Process xfs (pid: 909, stackpage=c4311000) Stack: c01e97a5 c01e9825 0606 c27cc680 0003 c431 c431 c0111d3b c5fe3f0c 01a8 c0196cfa 0003fff4 0003 c5c96c20 c431 0ff0 0206 c01963fe 0003fff0 0003 c2f8a164 0003ffec c01d1550 Call Trace: [c0111d3b] [c0196cfa] [c01963fe] [c01d1550] [c01d167e] [c01d1550] [c0193fad] [c01d1550] [c0194260] [c01942e2] [c0134763] [c01348c9] [c0108fc7] Code: 0f 0b 83 c4 0c 90 8d 74 26 00 31 c0 5b 5e 5f 5d 83 c4 0c c3 EIP; c012c056 kmalloc+112/128 = Trace; c0111d3b smp_call_function_interrupt+1f/34 Trace; c0196cfa alloc_skb+102/1a0 Trace; c01963fe sock_alloc_send_skb+72/12c Trace; c01d1550 unix_stream_sendmsg+0/310 Trace; c01d167e unix_stream_sendmsg+12e/310 Trace; c01d1550 unix_stream_sendmsg+0/310 Trace; c0193fad sock_sendmsg+81/a4 Trace; c01d1550 unix_stream_sendmsg+0/310 Trace; c0194260 sock_readv_writev+8c/98 Trace; c01942e2 sock_writev+36/40 Trace; c0134763 do_readv_writev+183/254 Trace; c01348c9 sys_writev+41/54 Trace; c0108fc7 system_call+37/40 Code; c012c056 kmalloc+112/128 _EIP: Code; c012c056 kmalloc+112/128 = 0: 0f 0b ud2a = Code; c012c058 kmalloc+114/128 2: 83 c4 0c add$0xc,%esp Code; c012c05b kmalloc+117/128 5: 90nop Code; c012c05c kmalloc+118/128 6: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c012c060 kmalloc+11c/128 a: 31 c0 xor%eax,%eax Code; c012c062 kmalloc+11e/128 c: 5bpop%ebx Code; c012c063 kmalloc+11f/128 d: 5epop%esi Code; c012c064 kmalloc+120/128 e: 5fpop%edi Code; c012c065 kmalloc+121/128 f: 5dpop%ebp Code; c012c066 kmalloc+122/128 10: 83 c4 0c add$0xc,%esp Code; c012c069 kmalloc+125/128 13: c3ret 1 warning issued. Results may not be reliable. kernel BUG at slab.c:1542! invalid operand: CPU:1 EIP:0010:[kmalloc+274/296] EFLAGS: 00010292 eax: 001b ebx: c27cc680 ecx: 0008 edx: c5802ca0 esi: 0003 edi: c431 ebp: c431 esp: c4311de4 ds: 0018 es: 0018 ss: 0018 Process xfs (pid: 909, stackpage=c4311000) Stack: c01e97a5 c01e9825 0606 c27cc680 0003 c431 c431 c0111d3b c5fe3f0c 01a8 c0196cfa 0003fff4 0003 c5c96c20 c431 0ff0 0206 c01963fe 0003fff0 0003 c2f8a164 0003ffec c01d1550 Call Trace: [smp_call_function_interrupt+31/52] [alloc_skb+258/416] [sock_alloc_send_skb+114/300] [unix_stream_sendmsg+0/784] [unix_stream_sendmsg+302/784] [unix_stream_sendmsg+0/784] [sock_sendmsg+129/164] [unix_stream_sendmsg+0/784] [sock_readv_writev+140/152] [sock_writev+54/64] [do_readv_writev+387/596] [sys_writev+65/84] [system_call+55/64] Code: 0f 0b 83 c4 0c 90 8d 74 26 00 31 c0 5b 5e 5f 5d 83 c4 0c c3 -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: APIC errors
"Maciej W. Rozycki" escribió: > > On Wed, 17 Jan 2001, Dominik Kubla wrote: > > > Just switched to 2.4.0-ac9 (+crypto patches) on our Dual-Pentium MMX > > webserver yesterday. Works fine so far, except i keep seeing those > > APIC erros (about 14 in 12 hrs) indicating receive, send and CS errors. > > > > Should i be concerned? > > At this volume I would treat this as a warning but not a critical issue. > Inter-APIC messages get retransmitted in case of an error, but the > checksum circuit is not sophisticated -- a double-bit error might pass > unnoticed leading to a system unstability under certain conditions. At > such a low volume of errors double-bit ones are not likely to happen. > > It's the first report of APIC errors on a P5 system I have seen, so it's > probably not a result of a bad motherboard design. I'd recommend to check > if the system doesn't get overheated. You may also be unlucky to have a > faulty board. > > Maciej > Hey, it's not the first, some time ago when it began to be reported a lot of people with various systems asked at the same time about the same thing :) I have a dual p200mmx in a Gigabyte 586DX mobo with 96Mb + Voodoo 3 2000pci, Realtek 8139 nic, bt848 tv... And I usually get a lot of these messages: [coma@quartz coma]$ cat /proc/interrupts CPU0 CPU1 0: 801148 819848IO-APIC-edge timer 1: 7576 7691IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 5: 0 4IO-APIC-edge soundblaster 8: 1 0IO-APIC-edge rtc 9: 4358 4347IO-APIC-edge eth1 12: 124492 126503IO-APIC-edge PS/2 Mouse 14: 206324 201592IO-APIC-edge ide0 15:15930941593085IO-APIC-edge ide1 17: 785989 785945 IO-APIC-level eth0 18:402433 IO-APIC-level bttv NMI:16209061620904 LOC:16209631620962 ERR: 2697 [coma@quartz coma]$ uptime 8:14pm up 4:30, 0 users, load average: 0.19, 0.11, 0.09 but my system works ok, mostly, now I have just upgraded a Realtek 8029 (10Mb) because it gets hung to a Realtek 8139 (100Mb) just to found the mobo has some kind of busmastering problems, but that's another story. P.D. And as you suggested it runs very hot, about 50ºC at the cpus when both are at full use. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?
Frank de Lange wrote: > > On Fri, Jan 12, 2001 at 09:51:36PM +0100, Ingo Molnar wrote: > > great. Back when i had the same problem, flood pinging another host (on > > the local network) was the quickest way to reproduce the hang: > > > > ping -f -s 10 otherhost > > > > this produced an IOAPIC-hang within seconds. > > Apart from killing streaming audio and interactive network use, nothing hangs. > As soon as the ping flood is stopped, audio streams on and ssh sessions are > useable again. So, it seems to fix it... > > Frank I do have a 3c503 and a ne2k-pci both of them use the 8390, I can hang the ne2k-pci easily by doing a ping -f, bigger packet size => early the hang. But I cannot hang the 3c503 by doing this. Now with 2.4.0 the ne2k-pci behaviour is that: doing a ping -f works for some amount of time, then stops for a BIG amount of time (various minutes), and then it works again (it seems), but at a much slower speed, and if you test it with normal ping (ping host) you don't get replies. The packets really go down to the wire and I even got replies. but I don't receive it. Previous versions of 2.4.0-testX caused ne2k-pci to hang and remain hanged until reboot. System: Mb Gigabyte 586dx, 2x200MMX, 96Mb RAM, -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?
Frank de Lange wrote: On Fri, Jan 12, 2001 at 09:51:36PM +0100, Ingo Molnar wrote: great. Back when i had the same problem, flood pinging another host (on the local network) was the quickest way to reproduce the hang: ping -f -s 10 otherhost this produced an IOAPIC-hang within seconds. Apart from killing streaming audio and interactive network use, nothing hangs. As soon as the ping flood is stopped, audio streams on and ssh sessions are useable again. So, it seems to fix it... Frank I do have a 3c503 and a ne2k-pci both of them use the 8390, I can hang the ne2k-pci easily by doing a ping -f, bigger packet size = early the hang. But I cannot hang the 3c503 by doing this. Now with 2.4.0 the ne2k-pci behaviour is that: doing a ping -f works for some amount of time, then stops for a BIG amount of time (various minutes), and then it works again (it seems), but at a much slower speed, and if you test it with normal ping (ping host) you don't get replies. The packets really go down to the wire and I even got replies. but I don't receive it. Previous versions of 2.4.0-testX caused ne2k-pci to hang and remain hanged until reboot. System: Mb Gigabyte 586dx, 2x200MMX, 96Mb RAM, -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: 2.4 kernel halting...
Scott Conway wrote: > > Hi, I'm having problems getting anything from > 2.4.0-test12 onward to get past the IDE detectin phase > of bootup, and not even 2.4.0-prerelease will work, > either. At the bottom of this is the output of dmesg, > on my current kernel (2.4.0-test11), with the spot > where test12+ freezes indicated. btw...does anyone > out there know how to capture output on a bad kernel; > since the one I'm having trouble with never gets far > enough for me to check for an oops with an externel > program? You can locate the point where I get the > freeze by the whole line of '*' to show where it locks > up. Also, please forward any replies to my e-mail > since I don't subscribe to linux-kernel due to > excessive traffic on my end. Thanks, and below is > dmesg output... > > Cut > Here--- > Linux version 2.4.0-test11-ac4 (root@ummagumma) (gcc > version 2.95.3 19991030 (prerelease)) #1 Wed Dec 27 > 03:15:22 EST 2000 Try to compile with kgcc or egcs, gcc 2.95 is not a recommended compiler, as it's know to miscompile somethings. Search Makefile for HOSTCC and CC and chage it if needed. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: 2.4 kernel halting...
Scott Conway wrote: Hi, I'm having problems getting anything from 2.4.0-test12 onward to get past the IDE detectin phase of bootup, and not even 2.4.0-prerelease will work, either. At the bottom of this is the output of dmesg, on my current kernel (2.4.0-test11), with the spot where test12+ freezes indicated. btw...does anyone out there know how to capture output on a bad kernel; since the one I'm having trouble with never gets far enough for me to check for an oops with an externel program? You can locate the point where I get the freeze by the whole line of '*' to show where it locks up. Also, please forward any replies to my e-mail since I don't subscribe to linux-kernel due to excessive traffic on my end. Thanks, and below is dmesg output... Cut Here--- Linux version 2.4.0-test11-ac4 (root@ummagumma) (gcc version 2.95.3 19991030 (prerelease)) #1 Wed Dec 27 03:15:22 EST 2000 Try to compile with kgcc or egcs, gcc 2.95 is not a recommended compiler, as it's know to miscompile somethings. Search Makefile for HOSTCC and CC and chage it if needed. -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: PROBLEM : Networking stops working with kernel 2.4.0-test11
pt: pin A routed to IRQ 18 > Region 0: I/O ports at d000 [size=8] > Region 1: I/O ports at d400 [size=4] > Region 4: I/O ports at d800 [size=256] > Expansion ROM at [disabled] [size=128K] > > 00:13.1 Unknown mass storage controller: Triones Technologies, Inc. > HPT366 (rev 01) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 120 (2000ns min, 2000ns max), cache line size 08 > Interrupt: pin B routed to IRQ 18 > Region 0: I/O ports at dc00 [size=8] > Region 1: I/O ports at e000 [size=4] > Region 4: I/O ports at e400 [size=256] > > /proc/scsi/scsi > > Attached devices: > Host: scsi0 Channel: 00 Id: 00 Lun: 00 > Vendor: IDE-CD Model: R/RW 4x4x24 Rev: 1.04 > Type: CD-ROM ANSI SCSI revision: 02 > > /proc/interrupts > >CPU0 CPU1 > 0: 122862 121853IO-APIC-edge timer > 1: 4209 3950IO-APIC-edge keyboard > 2: 0 0 XT-PIC cascade > 9: 0 0IO-APIC-edge acpi > 12: 31518 30952IO-APIC-edge PS/2 Mouse > 14: 10744 10757IO-APIC-edge ide0 > 15: 48575 49118IO-APIC-edge ide1 > 16: 4 1 IO-APIC-level bttv > 18: 12283 11918 IO-APIC-level eth0 > 19: 0 0 IO-APIC-level es1371 > NMI: 244639 244639 > LOC: 244049 243832 > ERR: 0 > > Note : I have a problem with my NIC : it has its MAC address set to > 00:00:00:00:00:00 by default and I have to force it to its real MAC > address specified in /etc/sysconfig/network-scripts/ifcfg-eth0. > > I hope this report might be of any use for you (and for me ;-) > Thanx > > -- Nono > e-mail : [EMAIL PROTECTED] > ICQ: 23137282 > tel: 06.84.05.03.51 (un petit message, ca fait tjs plaisir) > > - > 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/ I have an almos identical system as you, 2x200MMX motherboard (Gigabyte 586DX) also Voodoo3 (2000 pci) the same nic Realtek 8029AS, also a bt848 tv card, also SCSI (Aic-7880 onboard, but not used). I have reported it some time ago, and now all I get with 2.4.0-test11-pre4 and I think a additional patch is NETDEV WATCHDOG: eth0: transmit timed out, and something in the console about lost irq? I can't reproduce it with a uniprocesor kernel, and I have a 3c503 card wich uses the 8390 module, so I suppose that the problem it's not in the 8390, and it seems to be smp related. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: PROBLEM : Networking stops working with kernel 2.4.0-test11
: 00 Lun: 00 Vendor: IDE-CD Model: R/RW 4x4x24 Rev: 1.04 Type: CD-ROM ANSI SCSI revision: 02 /proc/interrupts CPU0 CPU1 0: 122862 121853IO-APIC-edge timer 1: 4209 3950IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 9: 0 0IO-APIC-edge acpi 12: 31518 30952IO-APIC-edge PS/2 Mouse 14: 10744 10757IO-APIC-edge ide0 15: 48575 49118IO-APIC-edge ide1 16: 4 1 IO-APIC-level bttv 18: 12283 11918 IO-APIC-level eth0 19: 0 0 IO-APIC-level es1371 NMI: 244639 244639 LOC: 244049 243832 ERR: 0 Note : I have a problem with my NIC : it has its MAC address set to 00:00:00:00:00:00 by default and I have to force it to its real MAC address specified in /etc/sysconfig/network-scripts/ifcfg-eth0. I hope this report might be of any use for you (and for me ;-) Thanx -- Nono e-mail : [EMAIL PROTECTED] ICQ: 23137282 tel: 06.84.05.03.51 (un petit message, ca fait tjs plaisir) - 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/ I have an almos identical system as you, 2x200MMX motherboard (Gigabyte 586DX) also Voodoo3 (2000 pci) the same nic Realtek 8029AS, also a bt848 tv card, also SCSI (Aic-7880 onboard, but not used). I have reported it some time ago, and now all I get with 2.4.0-test11-pre4 and I think a additional patch is NETDEV WATCHDOG: eth0: transmit timed out, and something in the console about lost irq? I can't reproduce it with a uniprocesor kernel, and I have a 3c503 card wich uses the 8390 module, so I suppose that the problem it's not in the 8390, and it seems to be smp related. -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: /proc/fb
Geert Uytterhoeven wrote:
>
> Hi Jorge,
>
> In linux-2.4.0-test12-pre2/Documentation/filesystems/proc.txt, you wrote:
>
> | fb Frame Buffer devices (2.4)
>
> This entry existed in 2.2 as well.
>
> Gr{oetje,eeting}s,
>
> Geert
>
Thanks, I put it 2.4 because in the original doc it didn't say anything
about it, and I don't use a 2.2 kernel since a long time.
--
Jorge Nerin
<[EMAIL PROTECTED]>
-
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/
Re: /proc/fb
Geert Uytterhoeven wrote:
Hi Jorge,
In linux-2.4.0-test12-pre2/Documentation/filesystems/proc.txt, you wrote:
| fb Frame Buffer devices (2.4)
This entry existed in 2.2 as well.
Gr{oetje,eeting}s,
Geert
Thanks, I put it 2.4 because in the original doc it didn't say anything
about it, and I don't use a 2.2 kernel since a long time.
--
Jorge Nerin
[EMAIL PROTECTED]
-
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/
Re: KERNEL BUG: console not working in linux
Gianluca Anzolin wrote: > > Hello > sorry if I'm mailing this twice, but there is a kernel bug in > linux 2.2 and linux 2.4. Linux 2.0 is not affected. I tested also > FreeBSD, OpenBSD, Windows 95 and DOS and they all work. > > The problem is that linux doesn't find the video card: after > lilo has loaded the kernel the screen becomes black. The system boots > regularily but the screen stays black forever. > > In this PC I haven't configured any framebuffer and there isn't > X Window. The video card is a TRIDENT 9660 and it is integrated on the > mainboard. > > I tried to access the system via ssh and I tried to issue the > lspci -xvv command. You can find the output (along with the output of > pciconf -l from FreeBSD) on http://www.gest.unipd.it/~iig0573/lspci.txt > lspci can't find the video card; FreeBSD finds it on 0:9.0 > > I tried then to boot with pci=direct, bios & conf1 (as somebody > told me) but anything changed. I tried also vga framebuffer and to pass > the vga=ask argument to the kernel. Nothing changed. > > With vga=ask the system asks to choose a video mode. The system > can also scan all the video modes of the card. But if I choose any of > them the screen becomes black. After some investigation I think the > problem is in arch/i386/boot/video.S but I haven't the skills to debug & > solve. > > Please, help me, I really hope to use linux on this PC... > otherwise I must use something else. > > Thank you, > > Gianluca > - > 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/ Are you sure you have enabled virtual terminal and console support in character devices, and vga text console in console drivers? -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: KERNEL BUG: console not working in linux
Gianluca Anzolin wrote: Hello sorry if I'm mailing this twice, but there is a kernel bug in linux 2.2 and linux 2.4. Linux 2.0 is not affected. I tested also FreeBSD, OpenBSD, Windows 95 and DOS and they all work. The problem is that linux doesn't find the video card: after lilo has loaded the kernel the screen becomes black. The system boots regularily but the screen stays black forever. In this PC I haven't configured any framebuffer and there isn't X Window. The video card is a TRIDENT 9660 and it is integrated on the mainboard. I tried to access the system via ssh and I tried to issue the lspci -xvv command. You can find the output (along with the output of pciconf -l from FreeBSD) on http://www.gest.unipd.it/~iig0573/lspci.txt lspci can't find the video card; FreeBSD finds it on 0:9.0 I tried then to boot with pci=direct, bios conf1 (as somebody told me) but anything changed. I tried also vga framebuffer and to pass the vga=ask argument to the kernel. Nothing changed. With vga=ask the system asks to choose a video mode. The system can also scan all the video modes of the card. But if I choose any of them the screen becomes black. After some investigation I think the problem is in arch/i386/boot/video.S but I haven't the skills to debug solve. Please, help me, I really hope to use linux on this PC... otherwise I must use something else. Thank you, Gianluca - 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/ Are you sure you have enabled virtual terminal and console support in character devices, and vga text console in console drivers? -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: ext2 compression: How about using the Netware principle?
Roy Sigurd Karlsbakk wrote: > > Hi > > With some years of practice with Novell NetWare, I've been wandering why > the (unused?) file system compression mechanism in ext2 is based on > doing realtime compression. To make compression efficient, it can't be > made this simple. Let's look at the type of volume (file system) > compression introduced with Novell NetWare 4.0 around '94: > > - A file is saved to disk > - If the file isn't touched (read or written to) within days > (default 14), the file is compressed. > - If the file isn't compressed more than percent (default 20), the > file is flagged "can't compress". > - All file compression is done on low traffic times (default between > 00:00 and 06:00 hours) > - The first time a file is read or written to within the days > interval mentioned above, the file is addressed using realtime > compression. The second time, the file is decompressed and commited to > disk (uncompressed). > > Results: > A minimum of CPU time is wasted compressing/decompressing files. > The average server I've been out working with have an effective > compression of somewhere between 30 and 100 per cent. > > PS: This functionality was even scheduled for Win2k, but was somewhere > lost... I don't know where... > > Questions: > I'm really not a kernel hacker, but really... > - The daily (or nightly) compression job can run as a cron job. This can > be a normal user process running as root. Am I right? > - The decompress-and-perhaps-commit-decompressed-to-disk process should > be done by a kernel process within (or beside) the file system. > - The M$ folks will get even more problems braging about a less useful > product. > > Please CC: to me, as I'm not on the list > > Regards > > Roy Sigurd Karlsbakk > Well, filesystem compresion is in NT since 4.0, in fact you can compress a file, a directory, or the whole partition, but only under NTFS. I believe that it's [un]compressed on the fly, but I'm not sure about this fact. The [un]compression mechanism could be a kernel thread calling a userspace program (gzip, bzip2, definable) doing the actual decompresion. Don't know, just thoughts. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: ext2 compression: How about using the Netware principle?
Roy Sigurd Karlsbakk wrote: Hi With some years of practice with Novell NetWare, I've been wandering why the (unused?) file system compression mechanism in ext2 is based on doing realtime compression. To make compression efficient, it can't be made this simple. Let's look at the type of volume (file system) compression introduced with Novell NetWare 4.0 around '94: - A file is saved to disk - If the file isn't touched (read or written to) within n days (default 14), the file is compressed. - If the file isn't compressed more than n percent (default 20), the file is flagged "can't compress". - All file compression is done on low traffic times (default between 00:00 and 06:00 hours) - The first time a file is read or written to within the n days interval mentioned above, the file is addressed using realtime compression. The second time, the file is decompressed and commited to disk (uncompressed). Results: A minimum of CPU time is wasted compressing/decompressing files. The average server I've been out working with have an effective compression of somewhere between 30 and 100 per cent. PS: This functionality was even scheduled for Win2k, but was somewhere lost... I don't know where... Questions: I'm really not a kernel hacker, but really... - The daily (or nightly) compression job can run as a cron job. This can be a normal user process running as root. Am I right? - The decompress-and-perhaps-commit-decompressed-to-disk process should be done by a kernel process within (or beside) the file system. - The M$ folks will get even more problems braging about a less useful product. Please CC: to me, as I'm not on the list Regards Roy Sigurd Karlsbakk Well, filesystem compresion is in NT since 4.0, in fact you can compress a file, a directory, or the whole partition, but only under NTFS. I believe that it's [un]compressed on the fly, but I'm not sure about this fact. The [un]compression mechanism could be a kernel thread calling a userspace program (gzip, bzip2, definable) doing the actual decompresion. Don't know, just thoughts. -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: [PATCH] Documentacion proc.txt update (2.4.x)
Dan Hollis wrote: > > On Mon, 20 Nov 2000, Jorge Nerin wrote: > > Well, this is a little update to the proc.txt file, it's based in 2.2 kernel, and >I have updated it a little to the 2.4 series, I have updated all the thing I have >been told in lk, so I submit this in order to include this in the main tree in order >to have a better updated info. > > > > +The latest versionof this document isavailable online at > > http://skaro.nightcrawler.com/~bb/Docs/Proc as HTML version. > > How about a working URL? > > traceroute to skaro.nightcrawler.com (216.186.140.118), 30 hops max, 38 byte packets > [...] > 11 pos3-0-0-155M.sjc-bb3.cerf.net (134.24.29.26) 66.400 ms 74.860 ms 68.486 ms > 12 dslnetworks1.dslnetworks.com (206.19.42.193) 105.303 ms 86.436 ms 68.749 ms > 13 206.16.72.114 (206.16.72.114) 79.867 ms 63.365 ms 59.919 ms > 14 * * * > 15 * * * > > -Dan Well, the URL came with the text, it was there before me ;-) I didn't work for me either, but I left it because I don't have a URL with the updated version online, even I don't have an updated version, I had to do it myself. I have left it because I don't have replies from the author nor from the website. -- Jorge Nerin <[EMAIL PROTECTED]> - 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] Documentacion proc.txt update (2.4.x)
Well, this is a little update to the proc.txt file, it's based in 2.2 kernel, and I have updated it a little to the 2.4 series, I have updated all the thing I have been told in lk, so I submit this in order to include this in the main tree in order to have a better updated info. diff -urN linux.old/Documentation/filesystems/proc.txt linux/Documentation/filesystems/proc.txt --- linux.old/Documentation/filesystems/proc.txtMon Nov 20 15:41:53 2000 +++ linux/Documentation/filesystems/proc.txtMon Nov 20 15:41:44 2000 @@ -3,8 +3,11 @@ -- /proc/sys Terrehon Bowden <[EMAIL PROTECTED]>October 7 1999 Bodo Bauer <[EMAIL PROTECTED]> + +2.4.x update Jorge Nerin <[EMAIL PROTECTED]> November 14 2000 -- -Version 1.2 Kernel version 2.2.12 +Version 1.3 Kernel version 2.2.12 + Kernel version 2.4.0-test11-pre4 -- Table of Contents @@ -42,17 +45,18 @@ 0.1 Introduction/Credits -This documentation is part of a soon (or so we hope) to be released book on -the SuSE Linux distribution. As there is no complete documentation for the -/proc file system and we've used many freely available sources to write these -chapters, it seems only fair to give the work back to the Linux community. -This work is based on the 2.2.* kernel version. I'm afraid it's still far from -complete, but we hope it will be useful. As far as we know, it is the first -'all-in-one' document about the /proc file system. It is focused on the Intel -x86 hardware, so if you are looking for PPC, ARM, SPARC, APX, etc., features, -you probably won't find what you are looking for. It also only covers IPv4 -networking, not IPv6 nor other protocols - sorry. But additions and patches -are welcome and will be added to this document if you mail them to Bodo. +This documentation is part of a soon (or so we hope) to be released book on +the SuSE Linux distribution. As there is no complete documentation for the +/proc file system and we've used many freely available sources to write these +chapters, it seems only fair to give the work back to the Linux community. +This work is based on the 2.2.* kernel version and the upcomming 2.4.*. I'm +afraid it's still far from complete, but we hope it will be useful. As far as +we know, it is the first 'all-in-one' document about the /proc file system. It +is focused on the Intel x86 hardware, so if you are looking for PPC, ARM, +SPARC, APX, etc., features, you probably won't find what you are looking for. +It also only covers IPv4 networking, not IPv6 nor other protocols - sorry. But +additions and patches are welcome and will be added to this document if you +mail them to Bodo. We'd like to thank Alan Cox, Rik van Riel, and Alexey Kuznetsov and a lot of other people for help compiling this documentation. We'd also like to extend a @@ -65,9 +69,13 @@ contact Bodo Bauer at [EMAIL PROTECTED] We'll be happy to add them to this document. -The latest version of this document is available online at +The latest versionof this document isavailable online at http://skaro.nightcrawler.com/~bb/Docs/Proc as HTML version. +If the above direction does not works for you, ypu could try the kernel +mailing list at [EMAIL PROTECTED] and/or try to reach me at [EMAIL PROTECTED] + 0.2 Legal Stuff --- @@ -92,7 +100,7 @@ The proc file system acts as an interface to internal data structures in the kernel. It can be used to obtain information about the system and to change -certain kernel parameters at runtime. +certain kernel parameters at runtime (sysctl). First, we'll take a look at the read-only parts of /proc. In Chapter 2, we show you how you can use /proc/sys to change settings. @@ -111,16 +119,17 @@ .. FileContent cmdline Command line arguments - environ Values of environment variables + cpuCurrent and last cpu in wich it was executed (2.4)(smp) + cwdLink to the current working directory + environ Values of environment variables + exeLink to the executable of this process fd Directory, which contains all file descriptors + maps Memory maps to executables and library files (2.4) mem Memory held by this process + root Link to the root directory of this process stat
[PATCH] Documentacion proc.txt update (2.4.x)
Well, this is a little update to the proc.txt file, it's based in 2.2 kernel, and I have updated it a little to the 2.4 series, I have updated all the thing I have been told in lk, so I submit this in order to include this in the main tree in order to have a better updated info. diff -urN linux.old/Documentation/filesystems/proc.txt linux/Documentation/filesystems/proc.txt --- linux.old/Documentation/filesystems/proc.txtMon Nov 20 15:41:53 2000 +++ linux/Documentation/filesystems/proc.txtMon Nov 20 15:41:44 2000 @@ -3,8 +3,11 @@ -- /proc/sys Terrehon Bowden [EMAIL PROTECTED]October 7 1999 Bodo Bauer [EMAIL PROTECTED] + +2.4.x update Jorge Nerin [EMAIL PROTECTED] November 14 2000 -- -Version 1.2 Kernel version 2.2.12 +Version 1.3 Kernel version 2.2.12 + Kernel version 2.4.0-test11-pre4 -- Table of Contents @@ -42,17 +45,18 @@ 0.1 Introduction/Credits -This documentation is part of a soon (or so we hope) to be released book on -the SuSE Linux distribution. As there is no complete documentation for the -/proc file system and we've used many freely available sources to write these -chapters, it seems only fair to give the work back to the Linux community. -This work is based on the 2.2.* kernel version. I'm afraid it's still far from -complete, but we hope it will be useful. As far as we know, it is the first -'all-in-one' document about the /proc file system. It is focused on the Intel -x86 hardware, so if you are looking for PPC, ARM, SPARC, APX, etc., features, -you probably won't find what you are looking for. It also only covers IPv4 -networking, not IPv6 nor other protocols - sorry. But additions and patches -are welcome and will be added to this document if you mail them to Bodo. +This documentation is part of a soon (or so we hope) to be released book on +the SuSE Linux distribution. As there is no complete documentation for the +/proc file system and we've used many freely available sources to write these +chapters, it seems only fair to give the work back to the Linux community. +This work is based on the 2.2.* kernel version and the upcomming 2.4.*. I'm +afraid it's still far from complete, but we hope it will be useful. As far as +we know, it is the first 'all-in-one' document about the /proc file system. It +is focused on the Intel x86 hardware, so if you are looking for PPC, ARM, +SPARC, APX, etc., features, you probably won't find what you are looking for. +It also only covers IPv4 networking, not IPv6 nor other protocols - sorry. But +additions and patches are welcome and will be added to this document if you +mail them to Bodo. We'd like to thank Alan Cox, Rik van Riel, and Alexey Kuznetsov and a lot of other people for help compiling this documentation. We'd also like to extend a @@ -65,9 +69,13 @@ contact Bodo Bauer at [EMAIL PROTECTED] We'll be happy to add them to this document. -The latest version of this document is available online at +The latest versionof this document isavailable online at http://skaro.nightcrawler.com/~bb/Docs/Proc as HTML version. +If the above direction does not works for you, ypu could try the kernel +mailing list at [EMAIL PROTECTED] and/or try to reach me at [EMAIL PROTECTED] + 0.2 Legal Stuff --- @@ -92,7 +100,7 @@ The proc file system acts as an interface to internal data structures in the kernel. It can be used to obtain information about the system and to change -certain kernel parameters at runtime. +certain kernel parameters at runtime (sysctl). First, we'll take a look at the read-only parts of /proc. In Chapter 2, we show you how you can use /proc/sys to change settings. @@ -111,16 +119,17 @@ .. FileContent cmdline Command line arguments - environ Values of environment variables + cpuCurrent and last cpu in wich it was executed (2.4)(smp) + cwdLink to the current working directory + environ Values of environment variables + exeLink to the executable of this process fd Directory, which contains all file descriptors + maps Memory maps to executables and library files (2.4) mem Memory held by this process + root Link to the root directory of this process statProcess status - status
Re: [PATCH] Documentacion proc.txt update (2.4.x)
Dan Hollis wrote: On Mon, 20 Nov 2000, Jorge Nerin wrote: Well, this is a little update to the proc.txt file, it's based in 2.2 kernel, and I have updated it a little to the 2.4 series, I have updated all the thing I have been told in lk, so I submit this in order to include this in the main tree in order to have a better updated info. +The latest versionof this document isavailable online at http://skaro.nightcrawler.com/~bb/Docs/Proc as HTML version. How about a working URL? traceroute to skaro.nightcrawler.com (216.186.140.118), 30 hops max, 38 byte packets [...] 11 pos3-0-0-155M.sjc-bb3.cerf.net (134.24.29.26) 66.400 ms 74.860 ms 68.486 ms 12 dslnetworks1.dslnetworks.com (206.19.42.193) 105.303 ms 86.436 ms 68.749 ms 13 206.16.72.114 (206.16.72.114) 79.867 ms 63.365 ms 59.919 ms 14 * * * 15 * * * -Dan Well, the URL came with the text, it was there before me ;-) I didn't work for me either, but I left it because I don't have a URL with the updated version online, even I don't have an updated version, I had to do it myself. I have left it because I don't have replies from the author nor from the website. -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: Documentation/proc.txt update
Jorge Nerin wrote: > > Jorge Nerin wrote: > > > > Jorge Nerin wrote: > > > > > > Hello, this is a patch with some updates to the Documetation/proc.txt > > > file, basically it contains updates to the new files in /proc/, new > > > files in /proc, and a paragraph about /proc/sys/net/ipv4/tcp_ecn. It's > > > far from complete, but it's a start point. > > > > > > > Well, netscape seems to wrap long lines, as Peter Samuelson noticed me, > > so I send it again as an attachment. > > > > -- > > Jorge Nerin > > <[EMAIL PROTECTED]> > > Another little update to the patch, this time with bits from Philipp > Matthias Hahn, and a little formating change to break a very long line > in the middle of a paragraph. > > -- > Jorge Nerin > <[EMAIL PROTECTED]> > - > 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/ I have to be more careful, I don't know if I forgot to attach the file or if the majordomo has dropped it?, probably the first one. So again, the update: (let's hope it doesn't wrap) --- old/proc.txtMon Oct 23 15:20:00 2000 +++ new/proc.txtWed Nov 15 00:04:48 2000 @@ -3,8 +3,11 @@ ------ /proc/sys Terrehon Bowden <[EMAIL PROTECTED]>October 7 1999 Bodo Bauer <[EMAIL PROTECTED]> + +2.4.x update Jorge Nerin <[EMAIL PROTECTED]> November 14 2000 -- -Version 1.2 Kernel version 2.2.12 +Version 1.3 Kernel version 2.2.12 + Kernel version 2.4.0-test11-pre4 -- Table of Contents @@ -42,17 +45,18 @@ 0.1 Introduction/Credits -This documentation is part of a soon (or so we hope) to be released book on -the SuSE Linux distribution. As there is no complete documentation for the -/proc file system and we've used many freely available sources to write these -chapters, it seems only fair to give the work back to the Linux community. -This work is based on the 2.2.* kernel version. I'm afraid it's still far from -complete, but we hope it will be useful. As far as we know, it is the first -'all-in-one' document about the /proc file system. It is focused on the Intel -x86 hardware, so if you are looking for PPC, ARM, SPARC, APX, etc., features, -you probably won't find what you are looking for. It also only covers IPv4 -networking, not IPv6 nor other protocols - sorry. But additions and patches -are welcome and will be added to this document if you mail them to Bodo. +This documentation is part of a soon (or so we hope) to be released book on +the SuSE Linux distribution. As there is no complete documentation for the +/proc file system and we've used many freely available sources to write these +chapters, it seems only fair to give the work back to the Linux community. +This work is based on the 2.2.* kernel version and the upcomming 2.4.*. I'm +afraid it's still far from complete, but we hope it will be useful. As far as +we know, it is the first 'all-in-one' document about the /proc file system. It +is focused on the Intel x86 hardware, so if you are looking for PPC, ARM, +SPARC, APX, etc., features, you probably won't find what you are looking for. +It also only covers IPv4 networking, not IPv6 nor other protocols - sorry. But +additions and patches are welcome and will be added to this document if you +mail them to Bodo. We'd like to thank Alan Cox, Rik van Riel, and Alexey Kuznetsov and a lot of other people for help compiling this documentation. We'd also like to extend a @@ -65,9 +69,13 @@ contact Bodo Bauer at [EMAIL PROTECTED] We'll be happy to add them to this document. -The latest version of this document is available online at +The latest versionof this document isavailable online at http://skaro.nightcrawler.com/~bb/Docs/Proc as HTML version. +If the above direction does not works for you, ypu could try the kernel +mailing list at [EMAIL PROTECTED] and/or try to reach me at [EMAIL PROTECTED] + 0.2 Legal Stuff --- @@ -92,7 +100,7 @@ The proc file system acts as an interface to internal data structures in the kernel. It can be used to obtain information about the system and to change -certain kernel parameters at runtime. +certain kernel parameters at runtime (sysctl). First, we'll take a look at the read-only parts of /proc. In
Re: Documentation/proc.txt update
Jorge Nerin wrote: Jorge Nerin wrote: Jorge Nerin wrote: Hello, this is a patch with some updates to the Documetation/proc.txt file, basically it contains updates to the new files in /proc/PID, new files in /proc, and a paragraph about /proc/sys/net/ipv4/tcp_ecn. It's far from complete, but it's a start point. Well, netscape seems to wrap long lines, as Peter Samuelson noticed me, so I send it again as an attachment. -- Jorge Nerin [EMAIL PROTECTED] Another little update to the patch, this time with bits from Philipp Matthias Hahn, and a little formating change to break a very long line in the middle of a paragraph. -- Jorge Nerin [EMAIL PROTECTED] - 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/ I have to be more careful, I don't know if I forgot to attach the file or if the majordomo has dropped it?, probably the first one. So again, the update: (let's hope it doesn't wrap) --- old/proc.txtMon Oct 23 15:20:00 2000 +++ new/proc.txtWed Nov 15 00:04:48 2000 @@ -3,8 +3,11 @@ -- /proc/sys Terrehon Bowden [EMAIL PROTECTED]October 7 1999 Bodo Bauer [EMAIL PROTECTED] + +2.4.x update Jorge Nerin [EMAIL PROTECTED] November 14 2000 -- -Version 1.2 Kernel version 2.2.12 +Version 1.3 Kernel version 2.2.12 + Kernel version 2.4.0-test11-pre4 -- Table of Contents @@ -42,17 +45,18 @@ 0.1 Introduction/Credits -This documentation is part of a soon (or so we hope) to be released book on -the SuSE Linux distribution. As there is no complete documentation for the -/proc file system and we've used many freely available sources to write these -chapters, it seems only fair to give the work back to the Linux community. -This work is based on the 2.2.* kernel version. I'm afraid it's still far from -complete, but we hope it will be useful. As far as we know, it is the first -'all-in-one' document about the /proc file system. It is focused on the Intel -x86 hardware, so if you are looking for PPC, ARM, SPARC, APX, etc., features, -you probably won't find what you are looking for. It also only covers IPv4 -networking, not IPv6 nor other protocols - sorry. But additions and patches -are welcome and will be added to this document if you mail them to Bodo. +This documentation is part of a soon (or so we hope) to be released book on +the SuSE Linux distribution. As there is no complete documentation for the +/proc file system and we've used many freely available sources to write these +chapters, it seems only fair to give the work back to the Linux community. +This work is based on the 2.2.* kernel version and the upcomming 2.4.*. I'm +afraid it's still far from complete, but we hope it will be useful. As far as +we know, it is the first 'all-in-one' document about the /proc file system. It +is focused on the Intel x86 hardware, so if you are looking for PPC, ARM, +SPARC, APX, etc., features, you probably won't find what you are looking for. +It also only covers IPv4 networking, not IPv6 nor other protocols - sorry. But +additions and patches are welcome and will be added to this document if you +mail them to Bodo. We'd like to thank Alan Cox, Rik van Riel, and Alexey Kuznetsov and a lot of other people for help compiling this documentation. We'd also like to extend a @@ -65,9 +69,13 @@ contact Bodo Bauer at [EMAIL PROTECTED] We'll be happy to add them to this document. -The latest version of this document is available online at +The latest versionof this document isavailable online at http://skaro.nightcrawler.com/~bb/Docs/Proc as HTML version. +If the above direction does not works for you, ypu could try the kernel +mailing list at [EMAIL PROTECTED] and/or try to reach me at [EMAIL PROTECTED] + 0.2 Legal Stuff --- @@ -92,7 +100,7 @@ The proc file system acts as an interface to internal data structures in the kernel. It can be used to obtain information about the system and to change -certain kernel parameters at runtime. +certain kernel parameters at runtime (sysctl). First, we'll take a look at the read-only parts of /proc. In Chapter 2, we show you how you can use /proc/sys to change settings. @@ -111,16 +119,17 @@ .. FileContent
Re: Documentation/proc.txt update
Jorge Nerin wrote: > > Jorge Nerin wrote: > > > > Hello, this is a patch with some updates to the Documetation/proc.txt > > file, basically it contains updates to the new files in /proc/, new > > files in /proc, and a paragraph about /proc/sys/net/ipv4/tcp_ecn. It's > > far from complete, but it's a start point. > > > > Well, netscape seems to wrap long lines, as Peter Samuelson noticed me, > so I send it again as an attachment. > > -- > Jorge Nerin > <[EMAIL PROTECTED]> Another little update to the patch, this time with bits from Philipp Matthias Hahn, and a little formating change to break a very long line in the middle of a paragraph. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
kernel BUG at sock.c:722! (2.4.0-test11-pre4)
Well, first saw this in test11-pre1, and now in test11-pre4 I report it
again.
Nov 14 15:10:51 quartz kernel: kernel BUG at sock.c:722!
Nov 14 15:10:51 quartz kernel: invalid operand:
Nov 14 15:10:51 quartz kernel: CPU:0
Nov 14 15:10:51 quartz kernel: EIP:0010:[sock_wait_for_wmem+104/244]
Nov 14 15:10:51 quartz kernel: EFLAGS: 00010286
Nov 14 15:10:51 quartz kernel: eax: 001a ebx: c1b2a000 ecx:
edx: 0002
Nov 14 15:10:51 quartz kernel: esi: c25c60e0 edi: c25c60e0 ebp:
7fff esp: c1b2be7c
Nov 14 15:10:51 quartz kernel: ds: 0018 es: 0018 ss: 0018
Nov 14 15:10:51 quartz kernel: Process sound-propertie (pid: 995,
stackpage=c1b2b000)
Nov 14 15:10:51 quartz kernel: Stack: c0216f45 c021718b 02d2
7fff c25c60e0 c1b2a000 0ff0 c1b2a000
Nov 14 15:10:51 quartz kernel: c1b2a000
c1b2a000
Nov 14 15:10:51 quartz kernel:c01a6829 c25c60e0 7fff
c5a81540 7fef c1b9 c19a74f4
Nov 14 15:10:51 quartz kernel: Call Trace: [vga_con+2501/10176]
[vga_con+3083/10176] [sock_alloc_send_skb+221/300]
[unix_stream_sendmsg+302/784] [unix_stream_sendmsg+0/784]
[sock_sendmsg+129/164] [unix_stream_sendmsg+0/784]
Nov 14 15:10:51 quartz kernel:[sock_write+163/172]
[sys_write+142/196] [system_call+55/64]
Nov 14 15:10:51 quartz kernel: Code: 0f 0b 83 c4 0c 8b 87 50 03 00 00 f0
0f ba 70 04 00 8d 4c 24
ksymoops 2.3.4 on i586 2.4.0-test11-pre4. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test11-pre4/ (default)
-m /boot/System.map-2.4.0-test11-pre4 (specified)
activating NMI Watchdog ... done.
cpu: 0, clocks: 668169, slice: 222723
cpu: 1, clocks: 668169, slice: 222723
invalid operand:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 001a ebx: c1b2a000 ecx: edx: 0002
esi: c25c60e0 edi: c25c60e0 ebp: 7fff esp: c1b2be7c
ds: 0018 es: 0018 ss: 0018
Process sound-propertie (pid: 995, stackpage=c1b2b000)
Stack: c0216f45 c021718b 02d2 7fff c25c60e0 c1b2a000 0ff0
c1b2a000
c1b2a000 c1b2a000
c01a6829 c25c60e0 7fff c5a81540 7fef c1b9 c19a74f4
Call Trace: [] [] [] []
[] [] []
[] [] []
Code: 0f 0b 83 c4 0c 8b 87 50 03 00 00 f0 0f ba 70 04 00 8d 4c 24
>>EIP; c01a66c0<=
Trace; c0216f45
Trace; c021718b
Trace; c01a6829
Trace; c01e2f2e
Trace; c01e2e00
Trace; c01a3a0d
Trace; c01e2e00
Trace; c01a3c2b
Trace; c013c81a
Trace; c010a0f7
Code; c01a66c0
<_EIP>:
Code; c01a66c0<=
0: 0f 0b ud2a <=
Code; c01a66c2
2: 83 c4 0c add$0xc,%esp
Code; c01a66c5
5: 8b 87 50 03 00 00 mov0x350(%edi),%eax
Code; c01a66cb
b: f0 0f ba 70 04 00 lock btrl $0x0,0x4(%eax)
Code; c01a66d1
11: 8d 4c 24 00 lea0x0(%esp,1),%ecx
--
Jorge Nerin
<[EMAIL PROTECTED]>
-
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/
kernel BUG at sock.c:722! (2.4.0-test11-pre4)
Well, first saw this in test11-pre1, and now in test11-pre4 I report it
again.
Nov 14 15:10:51 quartz kernel: kernel BUG at sock.c:722!
Nov 14 15:10:51 quartz kernel: invalid operand:
Nov 14 15:10:51 quartz kernel: CPU:0
Nov 14 15:10:51 quartz kernel: EIP:0010:[sock_wait_for_wmem+104/244]
Nov 14 15:10:51 quartz kernel: EFLAGS: 00010286
Nov 14 15:10:51 quartz kernel: eax: 001a ebx: c1b2a000 ecx:
edx: 0002
Nov 14 15:10:51 quartz kernel: esi: c25c60e0 edi: c25c60e0 ebp:
7fff esp: c1b2be7c
Nov 14 15:10:51 quartz kernel: ds: 0018 es: 0018 ss: 0018
Nov 14 15:10:51 quartz kernel: Process sound-propertie (pid: 995,
stackpage=c1b2b000)
Nov 14 15:10:51 quartz kernel: Stack: c0216f45 c021718b 02d2
7fff c25c60e0 c1b2a000 0ff0 c1b2a000
Nov 14 15:10:51 quartz kernel: c1b2a000
c1b2a000
Nov 14 15:10:51 quartz kernel:c01a6829 c25c60e0 7fff
c5a81540 7fef c1b9 c19a74f4
Nov 14 15:10:51 quartz kernel: Call Trace: [vga_con+2501/10176]
[vga_con+3083/10176] [sock_alloc_send_skb+221/300]
[unix_stream_sendmsg+302/784] [unix_stream_sendmsg+0/784]
[sock_sendmsg+129/164] [unix_stream_sendmsg+0/784]
Nov 14 15:10:51 quartz kernel:[sock_write+163/172]
[sys_write+142/196] [system_call+55/64]
Nov 14 15:10:51 quartz kernel: Code: 0f 0b 83 c4 0c 8b 87 50 03 00 00 f0
0f ba 70 04 00 8d 4c 24
ksymoops 2.3.4 on i586 2.4.0-test11-pre4. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test11-pre4/ (default)
-m /boot/System.map-2.4.0-test11-pre4 (specified)
activating NMI Watchdog ... done.
cpu: 0, clocks: 668169, slice: 222723
cpu: 1, clocks: 668169, slice: 222723
invalid operand:
CPU:0
EIP:0010:[c01a66c0]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 001a ebx: c1b2a000 ecx: edx: 0002
esi: c25c60e0 edi: c25c60e0 ebp: 7fff esp: c1b2be7c
ds: 0018 es: 0018 ss: 0018
Process sound-propertie (pid: 995, stackpage=c1b2b000)
Stack: c0216f45 c021718b 02d2 7fff c25c60e0 c1b2a000 0ff0
c1b2a000
c1b2a000 c1b2a000
c01a6829 c25c60e0 7fff c5a81540 7fef c1b9 c19a74f4
Call Trace: [c0216f45] [c021718b] [c01a6829] [c01e2f2e]
[c01e2e00] [c01a3a0d] [c01e2e00]
[c01a3c2b] [c013c81a] [c010a0f7]
Code: 0f 0b 83 c4 0c 8b 87 50 03 00 00 f0 0f ba 70 04 00 8d 4c 24
EIP; c01a66c0 sock_wait_for_wmem+68/f4 =
Trace; c0216f45 vga_con+9c5/27c0
Trace; c021718b vga_con+c0b/27c0
Trace; c01a6829 sock_alloc_send_skb+dd/12c
Trace; c01e2f2e unix_stream_sendmsg+12e/310
Trace; c01e2e00 unix_stream_sendmsg+0/310
Trace; c01a3a0d sock_sendmsg+81/a4
Trace; c01e2e00 unix_stream_sendmsg+0/310
Trace; c01a3c2b sock_write+a3/ac
Trace; c013c81a sys_write+8e/c4
Trace; c010a0f7 system_call+37/40
Code; c01a66c0 sock_wait_for_wmem+68/f4
_EIP:
Code; c01a66c0 sock_wait_for_wmem+68/f4 =
0: 0f 0b ud2a =
Code; c01a66c2 sock_wait_for_wmem+6a/f4
2: 83 c4 0c add$0xc,%esp
Code; c01a66c5 sock_wait_for_wmem+6d/f4
5: 8b 87 50 03 00 00 mov0x350(%edi),%eax
Code; c01a66cb sock_wait_for_wmem+73/f4
b: f0 0f ba 70 04 00 lock btrl $0x0,0x4(%eax)
Code; c01a66d1 sock_wait_for_wmem+79/f4
11: 8d 4c 24 00 lea0x0(%esp,1),%ecx
--
Jorge Nerin
[EMAIL PROTECTED]
-
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/
Re: Documentation/proc.txt update
Jorge Nerin wrote: Jorge Nerin wrote: Hello, this is a patch with some updates to the Documetation/proc.txt file, basically it contains updates to the new files in /proc/PID, new files in /proc, and a paragraph about /proc/sys/net/ipv4/tcp_ecn. It's far from complete, but it's a start point. Well, netscape seems to wrap long lines, as Peter Samuelson noticed me, so I send it again as an attachment. -- Jorge Nerin [EMAIL PROTECTED] Another little update to the patch, this time with bits from Philipp Matthias Hahn, and a little formating change to break a very long line in the middle of a paragraph. -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: Documentation/proc.txt update
Jorge Nerin wrote: > > Hello, this is a patch with some updates to the Documetation/proc.txt > file, basically it contains updates to the new files in /proc/, new > files in /proc, and a paragraph about /proc/sys/net/ipv4/tcp_ecn. It's > far from complete, but it's a start point. > Well, netscape seems to wrap long lines, as Peter Samuelson noticed me, so I send it again as an attachment. -- Jorge Nerin <[EMAIL PROTECTED]> --- old/proc.txtMon Oct 23 15:20:00 2000 +++ new/proc.txtMon Nov 13 00:20:24 2000 @@ -46,7 +46,7 @@ the SuSE Linux distribution. As there is no complete documentation for the /proc file system and we've used many freely available sources to write these chapters, it seems only fair to give the work back to the Linux community. -This work is based on the 2.2.* kernel version. I'm afraid it's still far from +This work is based on the 2.2.* kernel version and the upcomming 2.4.*. I'm afraid +it's still far from complete, but we hope it will be useful. As far as we know, it is the first 'all-in-one' document about the /proc file system. It is focused on the Intel x86 hardware, so if you are looking for PPC, ARM, SPARC, APX, etc., features, @@ -92,7 +92,7 @@ The proc file system acts as an interface to internal data structures in the kernel. It can be used to obtain information about the system and to change -certain kernel parameters at runtime. +certain kernel parameters at runtime (sysctl). First, we'll take a look at the read-only parts of /proc. In Chapter 2, we show you how you can use /proc/sys to change settings. @@ -111,16 +111,17 @@ .. FileContent cmdline Command line arguments - environ Values of environment variables + cpuCurrent and last cpu in wich it was executed (2.4)(smp) + cwdLink to the Current Working Directory + environ Values of environment variables + exeLink to the executable in the filesystem fd Directory, which contains all file descriptors + maps Maps to executables and library files (2.4) mem Memory held by this process + root Link to the root directory of this process statProcess status - status Process status in human readable form - cwd Link to the current working directory - exe Link to the executable of this process - mapsMemory maps - rootLink to the root directory of this process statm Process memory status information + status Process status in human readable form .. For example, to get the status information of a process, all you have to do is @@ -131,6 +132,7 @@ State: R (running) Pid:5452 PPid: 743 + TracerPid: 0(2.4) Uid:501 501 501 501 Gid:100 100 100 100 Groups: 100 14 16 @@ -187,13 +189,20 @@ devices Available devices (block and character) dma Used DMS channels filesystems Supported filesystems + driver Various drivers grouped here, currently rtc(2.4) + execdomains Execdomains, related to security (2.4) + fb Frame Buffer devices (2.4) + fs File system parameters, currently nfs/exports (2.4) ide Directory containing info about the IDE subsystem interrupts Interrupt usage + iomem Memory map (2.4) ioports I/O port usage - kcore Kernel core image (can be ELF or A.OUT) + irqMasks for irq to cpu affinity (2.4)(smp?) + isapnp ISA PnP (Plug) Info (2.4) + kcore Kernel core image (can be ELF or A.OUT(depreciated in 2.4)) kmsgKernel messages ksyms Kernel symbol table - loadavg Load average + loadavg Load average of last 1, 5 & 15 minutes locks Kernel locks meminfo Memory info miscMiscellaneous @@ -201,14 +210,19 @@ mounts Mounted filesystems net Networking info (see text) partitions Table of partitions known to the system +
Documentation/proc.txt update
e clock scsiSCSI info (see text) slabinfoSlab pool info statOverall statistics swaps Swap space utilization sys See chapter 2 + sysvipc Info of SysVIPC Resources (msg, sem, shm) (2.4) + ttyInfo of tty drivers uptime System uptime version Kernel version + video bttv info of video resources (2.4) .. You can, for example, check which interrupts are currently in use and what @@ -230,6 +244,68 @@ 15: 7 XT-PIC ide1 NMI: 0 +In 2.4.* a couple of lines where added to this file LOC & ERR (this time is the +output of a SMP machine): + + > cat /proc/interrupts + + CPU0 CPU1 +0:12434981214548IO-APIC-edge timer +1: 8949 8958IO-APIC-edge keyboard +2: 0 0 XT-PIC cascade +5: 11286 10161IO-APIC-edge soundblaster +8: 1 0IO-APIC-edge rtc +9: 27422 27407IO-APIC-edge 3c503 + 12: 113645 113873IO-APIC-edge PS/2 Mouse + 13: 0 0 XT-PIC fpu + 14: 22491 24012IO-APIC-edge ide0 + 15: 2183 2415IO-APIC-edge ide1 + 17: 30564 30414 IO-APIC-level eth0 + 18:177164 IO-APIC-level bttv + NMI:24579612457959 + LOC:24578822457881 + ERR: 2155 + +NMI is incremented in this case because every timer interrupt generates a NMI +(Non Maskable Interrupt) which is used by the NMI Watchdog to detect lookups. + +LOC is the local interrupt counter of the internal APIC of every CPU. + +ERR is incremented in the case of errors in the IO-APIC bus (the bus that +connects the CPUs in a SMP system. This means that an error has been detected, +the IO-APIC automatically retry the transmision, so it should not be a big +problem, but you should read the SMP-FAQ. + +In this context it could be interesting to note the new irq directory in 2.4. +It could be used to set IRQ to CPU affinity, this means that you can "hook" an +IRQ to only one CPU, or to exclude a CPU of handling IRQs. The contents of the +irq subdir is one subdir for each IRQ, and one file; prof_cpu_mask + +For example + > ls /proc/irq/ + 0 10 12 14 16 18 2 4 6 8 prof_cpu_mask + 1 11 13 15 17 19 3 5 7 9 + > ls /proc/irq/0/ + smp_affinity + +The contents of the prof_cpu_mask file and each smp_affinity file for each IRQ +is the same by default: + + > cat /proc/irq/0/smp_affinity + + +It's a bitmask, in wich you can specify wich CPUs can handle the IRQ, you can +set it by doing: + + > echo 1 > /proc/irq/prof_cpu_mask + +This means that only the first CPU will handle the IRQ, but you can also echo 5 +wich means that only the first and fourth CPU can handle the IRQ. + +The way IRQs are routed is handled by the IO-APIC, and it's Round Robin +between all the CPUs which are allowed to handle it. As usual the kernel has +more info than you and does a better job than you, so the defaults are the +best choice for almost everyone. There are three more important subdirectories in /proc: net, scsi, and sys. The general rule is that the contents, or even the existence of these @@ -1306,6 +1382,15 @@ TCP settings + +tcp_ecn +--- + +This file controls the use of the ECN bit in the IPv4 headers, this is a new +feature about Explicit Congestion Notification, but some routers and firewalls +block trafic that has this bit set, so it could be necessary to echo 0 to +/proc/sys/net/ipv4/tcp_ecn, if you want to talk to this sites. For more info +you could read RFC2481. tcp_retrans_collapse -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Documentation/proc.txt update
scsiSCSI info (see text) slabinfoSlab pool info statOverall statistics swaps Swap space utilization sys See chapter 2 + sysvipc Info of SysVIPC Resources (msg, sem, shm) (2.4) + ttyInfo of tty drivers uptime System uptime version Kernel version + video bttv info of video resources (2.4) .. You can, for example, check which interrupts are currently in use and what @@ -230,6 +244,68 @@ 15: 7 XT-PIC ide1 NMI: 0 +In 2.4.* a couple of lines where added to this file LOC ERR (this time is the +output of a SMP machine): + + cat /proc/interrupts + + CPU0 CPU1 +0:12434981214548IO-APIC-edge timer +1: 8949 8958IO-APIC-edge keyboard +2: 0 0 XT-PIC cascade +5: 11286 10161IO-APIC-edge soundblaster +8: 1 0IO-APIC-edge rtc +9: 27422 27407IO-APIC-edge 3c503 + 12: 113645 113873IO-APIC-edge PS/2 Mouse + 13: 0 0 XT-PIC fpu + 14: 22491 24012IO-APIC-edge ide0 + 15: 2183 2415IO-APIC-edge ide1 + 17: 30564 30414 IO-APIC-level eth0 + 18:177164 IO-APIC-level bttv + NMI:24579612457959 + LOC:24578822457881 + ERR: 2155 + +NMI is incremented in this case because every timer interrupt generates a NMI +(Non Maskable Interrupt) which is used by the NMI Watchdog to detect lookups. + +LOC is the local interrupt counter of the internal APIC of every CPU. + +ERR is incremented in the case of errors in the IO-APIC bus (the bus that +connects the CPUs in a SMP system. This means that an error has been detected, +the IO-APIC automatically retry the transmision, so it should not be a big +problem, but you should read the SMP-FAQ. + +In this context it could be interesting to note the new irq directory in 2.4. +It could be used to set IRQ to CPU affinity, this means that you can "hook" an +IRQ to only one CPU, or to exclude a CPU of handling IRQs. The contents of the +irq subdir is one subdir for each IRQ, and one file; prof_cpu_mask + +For example + ls /proc/irq/ + 0 10 12 14 16 18 2 4 6 8 prof_cpu_mask + 1 11 13 15 17 19 3 5 7 9 + ls /proc/irq/0/ + smp_affinity + +The contents of the prof_cpu_mask file and each smp_affinity file for each IRQ +is the same by default: + + cat /proc/irq/0/smp_affinity + + +It's a bitmask, in wich you can specify wich CPUs can handle the IRQ, you can +set it by doing: + + echo 1 /proc/irq/prof_cpu_mask + +This means that only the first CPU will handle the IRQ, but you can also echo 5 +wich means that only the first and fourth CPU can handle the IRQ. + +The way IRQs are routed is handled by the IO-APIC, and it's Round Robin +between all the CPUs which are allowed to handle it. As usual the kernel has +more info than you and does a better job than you, so the defaults are the +best choice for almost everyone. There are three more important subdirectories in /proc: net, scsi, and sys. The general rule is that the contents, or even the existence of these @@ -1306,6 +1382,15 @@ TCP settings + +tcp_ecn +--- + +This file controls the use of the ECN bit in the IPv4 headers, this is a new +feature about Explicit Congestion Notification, but some routers and firewalls +block trafic that has this bit set, so it could be necessary to echo 0 to +/proc/sys/net/ipv4/tcp_ecn, if you want to talk to this sites. For more info +you could read RFC2481. tcp_retrans_collapse -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: Documentation/proc.txt update
Jorge Nerin wrote: Hello, this is a patch with some updates to the Documetation/proc.txt file, basically it contains updates to the new files in /proc/PID, new files in /proc, and a paragraph about /proc/sys/net/ipv4/tcp_ecn. It's far from complete, but it's a start point. Well, netscape seems to wrap long lines, as Peter Samuelson noticed me, so I send it again as an attachment. -- Jorge Nerin [EMAIL PROTECTED] --- old/proc.txtMon Oct 23 15:20:00 2000 +++ new/proc.txtMon Nov 13 00:20:24 2000 @@ -46,7 +46,7 @@ the SuSE Linux distribution. As there is no complete documentation for the /proc file system and we've used many freely available sources to write these chapters, it seems only fair to give the work back to the Linux community. -This work is based on the 2.2.* kernel version. I'm afraid it's still far from +This work is based on the 2.2.* kernel version and the upcomming 2.4.*. I'm afraid +it's still far from complete, but we hope it will be useful. As far as we know, it is the first 'all-in-one' document about the /proc file system. It is focused on the Intel x86 hardware, so if you are looking for PPC, ARM, SPARC, APX, etc., features, @@ -92,7 +92,7 @@ The proc file system acts as an interface to internal data structures in the kernel. It can be used to obtain information about the system and to change -certain kernel parameters at runtime. +certain kernel parameters at runtime (sysctl). First, we'll take a look at the read-only parts of /proc. In Chapter 2, we show you how you can use /proc/sys to change settings. @@ -111,16 +111,17 @@ .. FileContent cmdline Command line arguments - environ Values of environment variables + cpuCurrent and last cpu in wich it was executed (2.4)(smp) + cwdLink to the Current Working Directory + environ Values of environment variables + exeLink to the executable in the filesystem fd Directory, which contains all file descriptors + maps Maps to executables and library files (2.4) mem Memory held by this process + root Link to the root directory of this process statProcess status - status Process status in human readable form - cwd Link to the current working directory - exe Link to the executable of this process - mapsMemory maps - rootLink to the root directory of this process statm Process memory status information + status Process status in human readable form .. For example, to get the status information of a process, all you have to do is @@ -131,6 +132,7 @@ State: R (running) Pid:5452 PPid: 743 + TracerPid: 0(2.4) Uid:501 501 501 501 Gid:100 100 100 100 Groups: 100 14 16 @@ -187,13 +189,20 @@ devices Available devices (block and character) dma Used DMS channels filesystems Supported filesystems + driver Various drivers grouped here, currently rtc(2.4) + execdomains Execdomains, related to security (2.4) + fb Frame Buffer devices (2.4) + fs File system parameters, currently nfs/exports (2.4) ide Directory containing info about the IDE subsystem interrupts Interrupt usage + iomem Memory map (2.4) ioports I/O port usage - kcore Kernel core image (can be ELF or A.OUT) + irqMasks for irq to cpu affinity (2.4)(smp?) + isapnp ISA PnP (PlugPlay) Info (2.4) + kcore Kernel core image (can be ELF or A.OUT(depreciated in 2.4)) kmsgKernel messages ksyms Kernel symbol table - loadavg Load average + loadavg Load average of last 1, 5 15 minutes locks Kernel locks meminfo Memory info miscMiscellaneous @@ -201,14 +210,19 @@ mounts Mounted filesystems net Networking info (see text) partitions Table of partitions known to the system + pciDepreciated info
Re: ping -f kills ne2k (was:[patch] NE2000)
Jorge Nerin wrote: > > Paul Gortmaker wrote: > > > > > > > > Well, I have tried it with 2.4.0-test10, both SMP and non-SMP, and the > > > result is a little confusing. > > > > > > Under SMP a ping -s 5 -f other_host takes down the network access > > > with no messages (ne2k-pci), and no possibility of being restored > > > without a reboot. > > > > > > Under UP the same command works ok, but after a while the dots stop for > > > 30sec, then ping prints an 'E' and the dots continue. strace revealed > > > this: > > > > Another suggestion - if you have your heart set on using ping > > as your network stress tool, you may want to try using multiple > > instances of MTU sized pings versus a single "ping -s 5". > > In this way you aren't involving any IP frag code and its associated > > bean counting - giving us one less factor to consider. > > > > Oh, and since you get a silent failure, maybe you would be interested > > in testing this patch I was (originally) saving for 2.5.x. -- It adds > > watchdog transmit timeout functionality to 8390.c (which is used by > > the ne2k-pci driver). Last time I updated it was a couple of months > > ago, but nothing has changed since then. > > > > Paul. > > > > Tested with ping -f -s 1400 (1400 in order not to reach 1500) > It took about half an hour and more than one million packets, but I > finally took the net down, with 12 concurrent pings. > > To eliminate factors I have deleted all the NAT rules wich gave messages > about dropped packets, and unloaded all the iptables modules. > > I have to make the test without the test check in sock_wait_for_wmem: > if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) > == 0) > BUG(); > > Because as I said in a previous msg it gave me BUG()s very early in the > tests, and I still had network access. > > If someone has a better sugestion as a nic stress tool I can try it, but > now I only have two ways of reaching this limits, ping -f of big > packets, and sometimes (only 4 or 5) during a copy of a large file over > NFS, but it's not a easy way to cause this. > > -- > Jorge Nerin > <[EMAIL PROTECTED]> Well, now it's kernel 2.4.0-test11-pre1 + 8390nmi, and the same conditions, about 8 pings concurrent, and this time it took only 202k packets to take the ne2k-pci down, but this time the watchdog says: Nov 9 16:00:52 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:52 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=1792. Nov 9 16:00:54 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:54 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:00:56 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:56 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:00:58 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:58 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:01:00 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:01:00 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:01:02 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:01:02 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. And never comes alive again. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: ping -f kills ne2k (was:[patch] NE2000)
Jorge Nerin wrote: Paul Gortmaker wrote: Well, I have tried it with 2.4.0-test10, both SMP and non-SMP, and the result is a little confusing. Under SMP a ping -s 5 -f other_host takes down the network access with no messages (ne2k-pci), and no possibility of being restored without a reboot. Under UP the same command works ok, but after a while the dots stop for 30sec, then ping prints an 'E' and the dots continue. strace revealed this: Another suggestion - if you have your heart set on using ping as your network stress tool, you may want to try using multiple instances of MTU sized pings versus a single "ping -s 5". In this way you aren't involving any IP frag code and its associated bean counting - giving us one less factor to consider. Oh, and since you get a silent failure, maybe you would be interested in testing this patch I was (originally) saving for 2.5.x. -- It adds watchdog transmit timeout functionality to 8390.c (which is used by the ne2k-pci driver). Last time I updated it was a couple of months ago, but nothing has changed since then. Paul. Tested with ping -f -s 1400 (1400 in order not to reach 1500) It took about half an hour and more than one million packets, but I finally took the net down, with 12 concurrent pings. To eliminate factors I have deleted all the NAT rules wich gave messages about dropped packets, and unloaded all the iptables modules. I have to make the test without the test check in sock_wait_for_wmem: if ((current-state (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0) BUG(); Because as I said in a previous msg it gave me BUG()s very early in the tests, and I still had network access. If someone has a better sugestion as a nic stress tool I can try it, but now I only have two ways of reaching this limits, ping -f of big packets, and sometimes (only 4 or 5) during a copy of a large file over NFS, but it's not a easy way to cause this. -- Jorge Nerin [EMAIL PROTECTED] Well, now it's kernel 2.4.0-test11-pre1 + 8390nmi, and the same conditions, about 8 pings concurrent, and this time it took only 202k packets to take the ne2k-pci down, but this time the watchdog says: Nov 9 16:00:52 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:52 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=1792. Nov 9 16:00:54 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:54 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:00:56 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:56 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:00:58 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:58 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:01:00 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:01:00 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:01:02 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:01:02 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. And never comes alive again. -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: ping -f kills ne2k (was:[patch] NE2000)
Paul Gortmaker wrote: > > > > > Well, I have tried it with 2.4.0-test10, both SMP and non-SMP, and the > > result is a little confusing. > > > > Under SMP a ping -s 5 -f other_host takes down the network access > > with no messages (ne2k-pci), and no possibility of being restored > > without a reboot. > > > > Under UP the same command works ok, but after a while the dots stop for > > 30sec, then ping prints an 'E' and the dots continue. strace revealed > > this: > > Another suggestion - if you have your heart set on using ping > as your network stress tool, you may want to try using multiple > instances of MTU sized pings versus a single "ping -s 5". > In this way you aren't involving any IP frag code and its associated > bean counting - giving us one less factor to consider. > > Oh, and since you get a silent failure, maybe you would be interested > in testing this patch I was (originally) saving for 2.5.x. -- It adds > watchdog transmit timeout functionality to 8390.c (which is used by > the ne2k-pci driver). Last time I updated it was a couple of months > ago, but nothing has changed since then. > > Paul. > Tested with ping -f -s 1400 (1400 in order not to reach 1500) It took about half an hour and more than one million packets, but I finally took the net down, with 12 concurrent pings. To eliminate factors I have deleted all the NAT rules wich gave messages about dropped packets, and unloaded all the iptables modules. I have to make the test without the test check in sock_wait_for_wmem: if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0) BUG(); Because as I said in a previous msg it gave me BUG()s very early in the tests, and I still had network access. If someone has a better sugestion as a nic stress tool I can try it, but now I only have two ways of reaching this limits, ping -f of big packets, and sometimes (only 4 or 5) during a copy of a large file over NFS, but it's not a easy way to cause this. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: [patch] NE2000
Andrew Morton wrote:
>
> Jorge Nerin wrote:
> >
> > ...
> > So I think that it could be a little window near sock_wait_for_wmem that
> > could be SMP insecure wich is affecting me.
> >
> > The code of sock_wait_for_wmem in 2.4.0-test10 is this:
> >
> > static long sock_wait_for_wmem(struct sock * sk, long timeo)
> > {
> > DECLARE_WAITQUEUE(wait, current);
> >
> > clear_bit(SOCK_ASYNC_NOSPACE, >socket->flags);
> > add_wait_queue(sk->sleep, );
> > for (;;) {
> > if (signal_pending(current))
> > break;
> > set_bit(SOCK_NOSPACE, >socket->flags);
> > set_current_state(TASK_INTERRUPTIBLE);
> > if (atomic_read(>wmem_alloc) < sk->sndbuf)
> > break;
> > if (sk->shutdown & SEND_SHUTDOWN)
> > break;
> > if (sk->err)
> > break;
> > timeo = schedule_timeout(timeo);
> > }
> > __set_current_state(TASK_RUNNING);
> > remove_wait_queue(sk->sleep, );
> > return timeo;
> > }
> >
> > Does someone see something SMP insecure? Perhaps I'm totally wrong, this
> > could also be somewhere in the interrupt handling, don't know.
>
> No, that code is correct, provided (current->state == TASK_RUNNING)
> on entry. If it isn't, there's a race window which can cause
> lost wakeups. As a check you could add:
>
> if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0)
> BUG();
>
> to the start of this function.
OK, added, the function now looks like this:
static long sock_wait_for_wmem(struct sock * sk, long timeo)
{
DECLARE_WAITQUEUE(wait, current);
if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE))
== 0)
BUG();
clear_bit(SOCK_ASYNC_NOSPACE, >socket->flags);
add_wait_queue(sk->sleep, );
for (;;) {
if (signal_pending(current))
break;
set_bit(SOCK_NOSPACE, >socket->flags);
set_current_state(TASK_INTERRUPTIBLE);
if (atomic_read(>wmem_alloc) < sk->sndbuf)
break;
if (sk->shutdown & SEND_SHUTDOWN)
break;
if (sk->err)
break;
timeo = schedule_timeout(timeo);
}
__set_current_state(TASK_RUNNING);
remove_wait_queue(sk->sleep, );
return timeo;
}
I have to put it _after_ DECLARE_WAITQUEUE in order to compile, if I put
it before it says me that wait is undeclared :-?
Well recompile, reboot, and got caugth by BUG(), after some tests.
[root@quartz ~]# ping -f -s 15000 pp_head
PING pp_head.pp.redvip.net (192.168.1.20) from 192.168.1.3 :
15000(15028) bytes of data.
..invalid operand:
CPU:0
EIP:0010:[]
EFLAGS: 00010296
eax: 001a ebx: c2604000 ecx: c021e2e8 edx: c0266440
esi: c26eeba0 edi: c26eeba0 ebp: 7fff esp: c2605c88
ds: 0018 es: 0018 ss: 0018
Process ping (pid: 2202, stackpage=c2605000)
Stack: c02047a5 c02049eb 02d2 7fff c26eeba0 c2604000
c26c4024
01234567 c2604000 01234567 c2604000
c0195c99 c26eeba0 7fff c26c4024 c264d0c0 c26c4010 05dc
Call Trace: [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] []
Code: 0f 0b 83 c4 0c 8b 87 50 03 00 00 f0 0f ba 70 04 00 8d 4c 24
Violación de segmento
[root@quartz ~]#
Nov 6 12:00:07 quartz kernel: kernel BUG at sock.c:722!
Nov 6 12:00:07 quartz kernel: invalid operand:
Nov 6 12:00:07 quartz kernel: CPU:0
Nov 6 12:00:07 quartz kernel: EIP:0010:[sock_wait_for_wmem+104/244]
Nov 6 12:00:07 quartz kernel: EFLAGS: 00010296
Nov 6 12:00:07 quartz kernel: eax: 001a ebx: c2604000 ecx:
c021e2e8 edx: c0266440
Nov 6 12:00:07 quartz kernel: esi: c26eeba0 edi: c26eeba0 ebp:
7fff esp: c2605c88
Nov 6 12:00:07 quartz kernel: ds: 0018 es: 0018 ss: 0018
Nov 6 12:00:07 quartz kernel: Process ping (pid: 2202,
stackpage=c2605000)
Nov 6 12:00:07 quartz kernel: Stack: c02047a5 c02049eb 02d2
7fff c26eeba0 c2604000 c26c4024
Nov 6 12:00:07 quartz kernel:01234567 c2604000
01234567 c2604000
Nov 6 12:00:07 quartz kernel:c0195c99 c26eeba0 7fff
c26c4024 c264d0c0 c26c4010 05dc
Nov 6 12:00:07 quartz kernel: Call Trace: [vga_con+2501/10176]
[vga_con+3083/10176] [sock_alloc_send_skb+221/300]
[ip_build_xmit_slow+378/1208] [ip_bu
Re: [patch] NE2000
Paul Gortmaker wrote:
>
> Jorge Nerin wrote:
>
> >
> > Ok, I reported it several times, but it gets ignored. I have a Realtek
> > 8029 (ne2k-pci), and with both drivers ne and ne2k-pci I can easily get
> > it stuck by doing a ping -f to a host in the local net, and sometimes it
> > happens doing copies to/from nfs shared resources.
> >
> > rmmod & insmod don't cure the problem, it seems that no interrupts are
> > delivered from the card, and there are no log messages, so a reboot is
> > needed to restore net access.
> >
> > System is dual 2x200mmx 96Mb ide discs no interrupts shared, and as far
> > as I can remember all kernel from 2.2.x, 2.3.x up to 2.4.0-testx exhibit
> > this problem.
>
> Any messages from the driver whatsoever? Does running a non-SMP
> kernel make the problem go away?
>
> Paul.
>
Well, I have tried it with 2.4.0-test10, both SMP and non-SMP, and the
result is a little confusing.
Under SMP a ping -s 5 -f other_host takes down the network access
with no messages (ne2k-pci), and no possibility of being restored
without a reboot.
Under UP the same command works ok, but after a while the dots stop for
30sec, then ping prints an 'E' and the dots continue. strace revealed
this:
sendmsg(4, {msg_name(16)={sin_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.1.20")}},
msg_iov(1)=[{"\10\0\305~|\23\231\0\v\317\2:\177\236\r\0\10\t\n\v\f\r"...,
50008}], msg_controllen=0, msg_flags=0}, 0x800) = 50008 <30.016855>
ping has been waiting for sendmsg to end for 30 seconds! I don't know if
this could be caused by filling the network buffers, and then waiting a
while while the nic sends it out. As the packet size increases (the -s
option) the stops are more frequent, there is still activity on the
network, but I don't know if they are my packets or the replies.
When ping is stopped it's stuck in sock_wait_for_wmem, and when it's
running it's (usually) in wait_for_packet.
So I think that it could be a little window near sock_wait_for_wmem that
could be SMP insecure wich is affecting me.
The code of sock_wait_for_wmem in 2.4.0-test10 is this:
static long sock_wait_for_wmem(struct sock * sk, long timeo)
{
DECLARE_WAITQUEUE(wait, current);
clear_bit(SOCK_ASYNC_NOSPACE, >socket->flags);
add_wait_queue(sk->sleep, );
for (;;) {
if (signal_pending(current))
break;
set_bit(SOCK_NOSPACE, >socket->flags);
set_current_state(TASK_INTERRUPTIBLE);
if (atomic_read(>wmem_alloc) < sk->sndbuf)
break;
if (sk->shutdown & SEND_SHUTDOWN)
break;
if (sk->err)
break;
timeo = schedule_timeout(timeo);
}
__set_current_state(TASK_RUNNING);
remove_wait_queue(sk->sleep, );
return timeo;
}
Does someone see something SMP insecure? Perhaps I'm totally wrong, this
could also be somewhere in the interrupt handling, don't know.
--
Jorge Nerin
<[EMAIL PROTECTED]>
-
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/
Re: [patch] NE2000
Paul Gortmaker wrote:
Jorge Nerin wrote:
Ok, I reported it several times, but it gets ignored. I have a Realtek
8029 (ne2k-pci), and with both drivers ne and ne2k-pci I can easily get
it stuck by doing a ping -f to a host in the local net, and sometimes it
happens doing copies to/from nfs shared resources.
rmmod insmod don't cure the problem, it seems that no interrupts are
delivered from the card, and there are no log messages, so a reboot is
needed to restore net access.
System is dual 2x200mmx 96Mb ide discs no interrupts shared, and as far
as I can remember all kernel from 2.2.x, 2.3.x up to 2.4.0-testx exhibit
this problem.
Any messages from the driver whatsoever? Does running a non-SMP
kernel make the problem go away?
Paul.
Well, I have tried it with 2.4.0-test10, both SMP and non-SMP, and the
result is a little confusing.
Under SMP a ping -s 5 -f other_host takes down the network access
with no messages (ne2k-pci), and no possibility of being restored
without a reboot.
Under UP the same command works ok, but after a while the dots stop for
30sec, then ping prints an 'E' and the dots continue. strace revealed
this:
sendmsg(4, {msg_name(16)={sin_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.1.20")}},
msg_iov(1)=[{"\10\0\305~|\23\231\0\v\317\2:\177\236\r\0\10\t\n\v\f\r"...,
50008}], msg_controllen=0, msg_flags=0}, 0x800) = 50008 30.016855
ping has been waiting for sendmsg to end for 30 seconds! I don't know if
this could be caused by filling the network buffers, and then waiting a
while while the nic sends it out. As the packet size increases (the -s
option) the stops are more frequent, there is still activity on the
network, but I don't know if they are my packets or the replies.
When ping is stopped it's stuck in sock_wait_for_wmem, and when it's
running it's (usually) in wait_for_packet.
So I think that it could be a little window near sock_wait_for_wmem that
could be SMP insecure wich is affecting me.
The code of sock_wait_for_wmem in 2.4.0-test10 is this:
static long sock_wait_for_wmem(struct sock * sk, long timeo)
{
DECLARE_WAITQUEUE(wait, current);
clear_bit(SOCK_ASYNC_NOSPACE, sk-socket-flags);
add_wait_queue(sk-sleep, wait);
for (;;) {
if (signal_pending(current))
break;
set_bit(SOCK_NOSPACE, sk-socket-flags);
set_current_state(TASK_INTERRUPTIBLE);
if (atomic_read(sk-wmem_alloc) sk-sndbuf)
break;
if (sk-shutdown SEND_SHUTDOWN)
break;
if (sk-err)
break;
timeo = schedule_timeout(timeo);
}
__set_current_state(TASK_RUNNING);
remove_wait_queue(sk-sleep, wait);
return timeo;
}
Does someone see something SMP insecure? Perhaps I'm totally wrong, this
could also be somewhere in the interrupt handling, don't know.
--
Jorge Nerin
[EMAIL PROTECTED]
-
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/
Re: [patch] NE2000
Alan Cox wrote: > > > This change sounds ok to me, if noone else objects. (I added to the CC > > a bit) I saw that code, and was thinking about doing the same thing > > myself. ne2k-pci.c definitely has changes which are not included in > > ne.c, and it seems silly to duplicate ne2000 PCI support. > > Unless there are any cards that need the bug workarounds in ne.c for use > on PCI then I see no problem. I've not heard of any. > Ok, I reported it several times, but it gets ignored. I have a Realtek 8029 (ne2k-pci), and with both drivers ne and ne2k-pci I can easily get it stuck by doing a ping -f to a host in the local net, and sometimes it happens doing copies to/from nfs shared resources. rmmod & insmod don't cure the problem, it seems that no interrupts are delivered from the card, and there are no log messages, so a reboot is needed to restore net access. System is dual 2x200mmx 96Mb ide discs no interrupts shared, and as far as I can remember all kernel from 2.2.x, 2.3.x up to 2.4.0-testx exhibit this problem. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: [patch] NE2000
Alan Cox wrote: This change sounds ok to me, if noone else objects. (I added to the CC a bit) I saw that code, and was thinking about doing the same thing myself. ne2k-pci.c definitely has changes which are not included in ne.c, and it seems silly to duplicate ne2000 PCI support. Unless there are any cards that need the bug workarounds in ne.c for use on PCI then I see no problem. I've not heard of any. Ok, I reported it several times, but it gets ignored. I have a Realtek 8029 (ne2k-pci), and with both drivers ne and ne2k-pci I can easily get it stuck by doing a ping -f to a host in the local net, and sometimes it happens doing copies to/from nfs shared resources. rmmod insmod don't cure the problem, it seems that no interrupts are delivered from the card, and there are no log messages, so a reboot is needed to restore net access. System is dual 2x200mmx 96Mb ide discs no interrupts shared, and as far as I can remember all kernel from 2.2.x, 2.3.x up to 2.4.0-testx exhibit this problem. -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: Minimizing dropped UDP packets
"Brian F. G. Bidulock" wrote: > > Frank, > > Have you considered checking /proc/net/dev_stat (first entry) > to see whether NET4 is dropping packets due to backlog > maximums? If there is a non-zero entry there, you might try > uping /proc/sys/net/core/netdev_max_backlog from the default > 300 and see if your loss diminishes. > > On Tue, 24 Oct 2000, Frank Hansen wrote: > > > Any suggestions whatsoever would be greatly appreciated. FWIW NT 4.0 > > running on the same hardware performs this task flawless, and I will > > have a diffucult time to convice my boss that we should use Linux as > > long as it is outperformed by NT. > > -- > Brian F. G. Bidulock > [EMAIL PROTECTED] > http://www.openss7.org/ Also you can try setsockopt with SO_RCVBUF, from man 7 socket: SO_RCVBUF Sets or gets the maximum socket receive buffer in bytes. The default value is set by the rmem_default sysctl and the maximum allowed value is set by the rmem_max sysctl. rmem_max defaults to 65535 perhaps you could try to increase this and then use setsockopt in your receiving program. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: Minimizing dropped UDP packets
"Brian F. G. Bidulock" wrote: Frank, Have you considered checking /proc/net/dev_stat (first entry) to see whether NET4 is dropping packets due to backlog maximums? If there is a non-zero entry there, you might try uping /proc/sys/net/core/netdev_max_backlog from the default 300 and see if your loss diminishes. On Tue, 24 Oct 2000, Frank Hansen wrote: Any suggestions whatsoever would be greatly appreciated. FWIW NT 4.0 running on the same hardware performs this task flawless, and I will have a diffucult time to convice my boss that we should use Linux as long as it is outperformed by NT. -- Brian F. G. Bidulock [EMAIL PROTECTED] http://www.openss7.org/ Also you can try setsockopt with SO_RCVBUF, from man 7 socket: SO_RCVBUF Sets or gets the maximum socket receive buffer in bytes. The default value is set by the rmem_default sysctl and the maximum allowed value is set by the rmem_max sysctl. rmem_max defaults to 65535 perhaps you could try to increase this and then use setsockopt in your receiving program. -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: bonding.c and proc_fs
Willy TARREAU wrote: > > Hello ! > > I think that you should wait a bit before writing a config in /proc for the > bonding driver. > I have rewritten quite a part of it to support link detection and make it a bit > fail safe. > Moreover, I had to rewrite partly ifenslave.c (which is included in the same > patch). Everything > *seems* to work fine (even in SMP now) and I've submitted this to Thomas Davis > after > Constantine Gavrilov has done some tests. If you're interested in, I can send > you the currently > working patch (with longer doc). It may change the way you planned your > configuration in /proc. > > Regards, > > Willy Sorry for the AOLism, but... Me too, I also want to give a try to the patch. I also want to try bonding between two machines, one 486 and one dual 200mmx, and until now without luck, I only managed to lockup the dual machine by doing ifconfig up & down and insmod & rmmod, mostly because the lack of documentation. Thanks. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: 2.2.x NFS service causing routing/networking failures?
David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > Okay, twice this evening I've seen my 2.2.16-kernel based i586 (K6-2) > > machine become ignorant of the utility of eth0. Both times I'd been > > playing mp3 audio on another linux box from an NFS volume served by > > the machine that went nuts. > > Let me guess - eth0 is a tulip card? Try a different driver. There are > three in the kernel sources - de4x5, tulip and old_tulip. > > You're probably using 'tulip'. Switch to 'old_tulip'. Hello, I'm using a realtek 8029 (ne2k-pci) that sometimes hungs, it stops working, nothing in the logs, no more interrupts, no respond to either ip or arp. ifdown & ifup don't solve it, neither rmmod insmod (ne2k-pci, 8390), and BTW a 3c503 in the same machine continues to work ok (8390 based also). So, a silent drop off the net and no other solution than a reboot. > > -- > dwmw2 -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Re: 2.2.x NFS service causing routing/networking failures?
David Woodhouse wrote: [EMAIL PROTECTED] said: Okay, twice this evening I've seen my 2.2.16-kernel based i586 (K6-2) machine become ignorant of the utility of eth0. Both times I'd been playing mp3 audio on another linux box from an NFS volume served by the machine that went nuts. Let me guess - eth0 is a tulip card? Try a different driver. There are three in the kernel sources - de4x5, tulip and old_tulip. You're probably using 'tulip'. Switch to 'old_tulip'. Hello, I'm using a realtek 8029 (ne2k-pci) that sometimes hungs, it stops working, nothing in the logs, no more interrupts, no respond to either ip or arp. ifdown ifup don't solve it, neither rmmod insmod (ne2k-pci, 8390), and BTW a 3c503 in the same machine continues to work ok (8390 based also). So, a silent drop off the net and no other solution than a reboot. -- dwmw2 -- Jorge Nerin [EMAIL PROTECTED] - 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/
Re: Software RAID
Steve Hill wrote: > > Has anyone had any problems with software RAID causing high loadaverage > peaks? I've got a number of i586 boxes here, dual IDE controllers, one > drive on each controller. They're using RAID 1 across the two > drives. Every few hours, the load average peaks very high, and it appears > to be the RAID (identacal boxes, running identical software but without > the RAID don't seem to have the problem). > > Is this normal, or is something broken on these boxes? > > -- > > - Steve Hill > System Administrator Email: [EMAIL PROTECTED] > Navaho Technologies Ltd. Tel: +44-870-7034015 Well I do have a 486dx2 (66Mhz-24Mb RAM) Root RAID 0 using three disks, and as far as I can see there are no spikes and the box runs smoothly. Perhaps it's a cron job or some daemon. -- Jorge Nerin <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> - 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/
Re: Software RAID
Steve Hill wrote: Has anyone had any problems with software RAID causing high loadaverage peaks? I've got a number of i586 boxes here, dual IDE controllers, one drive on each controller. They're using RAID 1 across the two drives. Every few hours, the load average peaks very high, and it appears to be the RAID (identacal boxes, running identical software but without the RAID don't seem to have the problem). Is this normal, or is something broken on these boxes? -- - Steve Hill System Administrator Email: [EMAIL PROTECTED] Navaho Technologies Ltd. Tel: +44-870-7034015 Well I do have a 486dx2 (66Mhz-24Mb RAM) Root RAID 0 using three disks, and as far as I can see there are no spikes and the box runs smoothly. Perhaps it's a cron job or some daemon. -- Jorge Nerin [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2)
Hello, using 2.4.0-test9-pre2 and thinking that there are no major bugs I found this again, I have observed what I think it's the same bug since 2.4.0-test7. All the traces end up in stext_lock, so I think it' the same bug, this time it happened when I was about to use the iomega parport zip with autofs. The modprobe of ppa failed but it was inserted (???) because of the rename of sd.o back again to sd_mod.o ksymoops 2.3.4 on i586 2.4.0-test9-pre2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test9-pre2/ (default) -m /boot/System.map-2.4.0-test9-pre2 (specified) cpu: 0, clocks: 668188, slice: 222729 cpu: 1, clocks: 668188, slice: 222729 NMI Watchdog detected LOCKUP on CPU1, registers: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 0082 eax: 0306 ebx: 0246 ecx: 0006 edx: 0041b1cb esi: 0306 edi: 000c ebp: 5864 esp: c583ded8 ds: 0018 es: 0018 ss: 0018 Process syslogd (pid: 389, stackpage=c583d000) Stack: c28aaf80 0002 c015db32 0306 c28aaf80 0001 c28aaf80 0006 c015dd03 0001 c28aaf80 c28aad40 c10e7878 c38ee8bc 0400 c01256b5 0001 0001 c583df30 c1054460 c28aaf80 c012576e Call Trace: [] [] [] [] [] [] [] [] [] Code: f3 90 7e f5 e9 a6 da f7 ff 80 3d 90 e7 21 c0 00 f3 90 7e f5 >>EIP; c01df3aa<= Trace; c015db32 Trace; c015dd03 Trace; c01256b5 Trace; c012576e Trace; c01257cd Trace; c0125680 Trace; c0150c6d Trace; c0133526 Trace; c01094b7 Code; c01df3aa <_EIP>: Code; c01df3aa<= 0: f3 90 repz nop<= Code; c01df3ac 2: 7e f5 jlefff9 <_EIP+0xfff9> c01df3a3 Code; c01df3ae 4: e9 a6 da f7 ffjmpfff7daaf <_EIP+0xfff7daaf> c015ce59 Code; c01df3b3 9: 80 3d 90 e7 21 c0 00 cmpb $0x0,0xc021e790 Code; c01df3ba 10: f3 90 repz nop Code; c01df3bc 12: 7e f5 jle9 <_EIP+0x9> c01df3b3 NMI Watchdog detected LOCKUP on CPU0, registers: CPU:0 EIP:0010:[] EFLAGS: 0082 eax: 0306 ebx: 0246 ecx: 0006 edx: 0041b1cb esi: 0306 edi: 000c ebp: 801e esp: c5fb1f74 ds: 0018 es: 0018 ss: 0018 Process kflushd (pid: 5, stackpage=c5fb1000) Stack: c5edeaa0 0002 c015db32 0306 c5edeaa0 0001 c5edeaa0 0006 c015dd03 0001 c5edeaa0 0007 c14e2260 0001 c5fb 0400 c0136149 0001 0001 c5fb1fd8 0001 c5fb 0ad0 Call Trace: [] [] [] [] [] Code: f3 90 7e f5 e9 a6 da f7 ff 80 3d 90 e7 21 c0 00 f3 90 7e f5 >>EIP; c01df3aa<= Trace; c015db32 Trace; c015dd03 Trace; c0136149 Trace; c01363fd Trace; c01079bb Code; c01df3aa <_EIP>: Code; c01df3aa<= 0: f3 90 repz nop<= Code; c01df3ac 2: 7e f5 jlefff9 <_EIP+0xfff9> c01df3a3 Code; c01df3ae 4: e9 a6 da f7 ffjmpfff7daaf <_EIP+0xfff7daaf> c015ce59 Code; c01df3b3 9: 80 3d 90 e7 21 c0 00 cmpb $0x0,0xc021e790 Code; c01df3ba 10: f3 90 repz nop Code; c01df3bc 12: 7e f5 jle9 <_EIP+0x9> c01df3b3 -- Jorge Nerin <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> - 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/
[OT] incremental patch of two patches?
This is a little offtopic, but as everybody here uses patches everyday,, someone migth have an answer for this. How can I make a incremental patch of two other patches without making two trees? Let me explain, I want to know what has changed between test8-pre4 and test8-pre5, I remember sometime ago that this question or something similar has been answered, but the infamous truncate but bit some of my mailboxes and I can't find it. I think that this can be done without even using the original tree, only using the patches, but I cant find a way. Thanks. -- Jorge Nerin <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> - 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/
[OT] incremental patch of two patches?
This is a little offtopic, but as everybody here uses patches everyday,, someone migth have an answer for this. How can I make a incremental patch of two other patches without making two trees? Let me explain, I want to know what has changed between test8-pre4 and test8-pre5, I remember sometime ago that this question or something similar has been answered, but the infamous truncate but bit some of my mailboxes and I can't find it. I think that this can be done without even using the original tree, only using the patches, but I cant find a way. Thanks. -- Jorge Nerin [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: Long uptime (~1 yr) => broken load averages (2.2.12)
Neal H Walfield wrote: > > Hello, > > I am running Linux 2.2.12: > > neal@colo:~$ cat /proc/version > Linux version 2.2.12 (root@gondor) (gcc version 2.95.1 19990816 (release)) > #1 Sun Sep 12 00:22:57 EST 1999 > > Starting twelve days ago the load average has increased by one every > twenty-four hours. Normally, it remains close to 0. At the moment, they > are at twelve; I imagine that tomorrow, they will be at thirteen: > > neal@colo:~$ w > 11:08am up 330 days, 17:36, 1 user, load average: 12.08, 12.05, 12.01 > USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT > neal ttyp0qui182p.star.net 10:02am 0.00s 0.33s 0.12s w > > Other than this, the system appears to be functioning normally. I do not > know where to start looking for the bug, however, I will be happy to > provide any additional details that could be of help. > > Regards, > -Neal > You may have stuck processes wich doesn't run but count as active for the load avg count. Almost all processes that get stuck in D state and can't be killed increases the load avg by one per process stuck. So look for processes in zombie state or D state. If you can't kill them perhaps you will need to reboot. If it increases slowly it could be another thing, but if it increases suddenly at a fixed time it could be a cron job. -- Jorge Nerin <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> - 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/
Re: Long uptime (~1 yr) = broken load averages (2.2.12)
Neal H Walfield wrote: Hello, I am running Linux 2.2.12: neal@colo:~$ cat /proc/version Linux version 2.2.12 (root@gondor) (gcc version 2.95.1 19990816 (release)) #1 Sun Sep 12 00:22:57 EST 1999 Starting twelve days ago the load average has increased by one every twenty-four hours. Normally, it remains close to 0. At the moment, they are at twelve; I imagine that tomorrow, they will be at thirteen: neal@colo:~$ w 11:08am up 330 days, 17:36, 1 user, load average: 12.08, 12.05, 12.01 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT neal ttyp0qui182p.star.net 10:02am 0.00s 0.33s 0.12s w Other than this, the system appears to be functioning normally. I do not know where to start looking for the bug, however, I will be happy to provide any additional details that could be of help. Regards, -Neal You may have stuck processes wich doesn't run but count as active for the load avg count. Almost all processes that get stuck in D state and can't be killed increases the load avg by one per process stuck. So look for processes in zombie state or D state. If you can't kill them perhaps you will need to reboot. If it increases slowly it could be another thing, but if it increases suddenly at a fixed time it could be a cron job. -- Jorge Nerin [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
