Re: Linux 2.4.5-ac15 / 2.4.6-pre5
Mike Galbraith schrieb am Freitag, den 22. Juni 2001: > > 6 5 1 77232 2692 2136 47004 560 892 2048 1524 10428 285529 2 98 0 >^ > Was disk running? (I bet not.. bet it stopped just after stall began) There was no disk activity during the stall. Walter - 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: Linux 2.4.5-ac15 / 2.4.6-pre5
Mike Galbraith schrieb am Donnerstag, den 21. Juni 2001: > On Thu, 21 Jun 2001, Marcelo Tosatti wrote: > > > > 2 4 2 77084 1524 18396 66904 0 1876 108 2220 2464 66079 198 1 >^ > > Ok, I suspect that GFP_BUFFER allocations are fucking up here (they can't > > block on IO, so they loop insanely). > > Why doesn't the VM hang the syncing of queued IO on these guys via > wait_event or such instead of trying to just let the allocation fail? > (which seems to me will only cause the allocation to be resubmitted, > effectively changing nothing but adding overhead) Does failing the > allocation in fact accomplish more than what I'm (uhoh:) assuming? Ok, I managed to press SysRq-T this time ond got a trace for my hang. Symbols are resolved by klog. If you prefer ksymopps please tell me, I used klog because ksymopps seems to drop all lines without symbols. There seem to be no kernel deamons in the trace? Is this normal, or is the log buffer too small? If it is the latter, how can I increase its size? Kernel was 2.4.6pre5 plus Rik's patch (at the end). I see the same hangs with the ac series. Walter Jun 22 15:42:09 frodo kernel: 2672 1021 1 1035 (NOTLB)1050 1004 Jun 22 15:42:10 frodo kernel: Call Trace: [sys_wait4+875/924] [system_call+51/56] Jun 22 15:42:10 frodo kernel: mysqldS 7FFF 0 1035 1021 1055 (NOTLB) Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+23/152] [do_select+153/520] [sys_select+1071/1436] [system_call+51/56] Jun 22 15:42:10 frodo kernel: smbd S 7FFF 0 1050 1(NOTLB) 1051 1021 Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+23/152] [do_select+153/520] [sys_select+1071/1436] [system_call+51/56] Jun 22 15:42:10 frodo kernel: sshd S 7FFF 0 1051 1(NOTLB) 1060 1050 Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+23/152] [do_select+153/520] [sys_select+1071/1436] [system_call+51/56] Jun 22 15:42:10 frodo kernel: mysqldR 5644 1055 1035 1056 (NOTLB) Jun 22 15:42:10 frodo kernel: Call Trace: [__alloc_pages+272/656] [_alloc_pages+24/28] [__get_free_pages+10/24] [__pollwait+51/148] [pipe_poll+38/100] [do_pollfd+94/176] [do_poll+167/228] Jun 22 15:42:10 frodo kernel:[sys_poll+603/884] [system_call+51/56] Jun 22 15:42:10 frodo kernel: mysqldS C5C8A000 5704 1056 1055(NOTLB) Jun 22 15:42:10 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:10 frodo kernel: wwwoffled S C5F7BF10 2672 1060 1 4417 (NOTLB) 1064 1051 Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+120/152] [process_timeout+0/76] [do_select+153/520] [sys_select+1071/1436] [system_call+51/56] Jun 22 15:42:10 frodo kernel: cron S C5F5DF7C 0 1064 1(NOTLB) 1068 1060 Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+120/152] [process_timeout+0/76] [sys_nanosleep+304/428] [system_call+51/56] Jun 22 15:42:10 frodo kernel: in.identd S 7FFF 0 1068 1 1070 (NOTLB) 1083 1064 Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+23/152] [wait_for_connect+308/420] [tcp_accept+134/408] [inet_accept+48/316] [sys_accept+102/244] [do_fork+1567/1756] [schedule+714/1064] Jun 22 15:42:10 frodo kernel:[restore_sigcontext+273/312] [sys_socketcall+172/476] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd R 3444 1070 1068 1081 (NOTLB) Jun 22 15:42:11 frodo kernel: Call Trace: [__alloc_pages+272/656] [_alloc_pages+24/28] [__get_free_pages+10/24] [sys_poll+310/884] [handle_IRQ_event+49/92] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd S C5B7A00016 1071 1070(NOTLB) 1076 Jun 22 15:42:11 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd S C7806000 0 1076 1070(NOTLB) 1077 1071 Jun 22 15:42:11 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd S C7FBC000 0 1077 1070(NOTLB) 1078 1076 Jun 22 15:42:11 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd S C7FB8000 2676 1078 1070(NOTLB) 1081 1077 Jun 22 15:42:11 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd S C6964000 0 1081 1070(NOTLB) 1078 Jun 22 15:42:11 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:11 frodo kernel: nscd S C739BF14 0 1083 1 1085 (NOTLB) 1098 1068 Jun 22 15:42:11 frodo kernel: Call Trace: [schedule_timeout+120/152] [process_timeout+0/76] [do_poll+55/228] [sys_poll+603/884] [sys_newstat+103/116]
Re: Linux 2.4.5-ac15
On Wed, 20 Jun 2001, Rik van Riel wrote: > > FWIW, here is the vmstat output for the second (short) hang. Taken with > > ac14, vmstat 1 was started (long) before the hang and interrupted about > > five seconds after it. The machine has 128MB RAM and 256MB swap. > > >procs memoryswap io system cpu > > r b w swpd free buff cache si sobibo incs us sy id > > 1 0 0 77000 1464 18444 67324 8 0 152 224 386 1345 26 19 55 > > 2 4 2 77084 1524 18396 66904 0 1876 108 2220 2464 66079 1 98 1 > > Does the following patch help with this problem, or are > you both experiencing something unrelated to this particular > buglet ? Hi Rik, I tried 2.4.6-pre5 with your patch (quoted at the end). Oberservations: I still see this hang, it seemed to last longer than with ac14/ac15 (say, 30 seconds). There was no heavy swapping going on, eiter before or after the hang. During the hang there was no disc activity. Compared with 2.4.5ac I saw that 2.4.6-pre5 uses much less swap (according to xosview). With the load I tried (many open browser windows) the ac series used to use 80-100MB of swap; 2.4.6-pre5 only used 40MB swap for roughly the same number of windows open. I forgot to press SysRq-T to get a trace, I'm afraid. kdb didn't compile with this kernel either (although patching worked). I had vmstat running in another window and stopped it a couple of seconds after the hang, here are the last line of its output: procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 0 0 36424 3232888 45036 0 0 4 0 255 3250 56 13 32 1 0 0 36424 3096888 45048 0 012 0 140 1010 37 6 58 4 0 0 36424 2964888 45060 0 012 0 228 1304 90 6 4 3 0 0 36424 3052900 44668 0 088 0 259 2522 88 12 0 2 0 0 36424 3164900 44524 0 0 4 0 144 3556 87 13 0 3 0 0 36424 2812900 44468 0 0 8 0 211 2007 87 11 3 5 0 0 36424 2812912 44108 0 020 0 196 1243 92 8 0 4 0 0 36424 2812920 43836 0 0 108 0 271 2928 88 12 0 4 0 0 36424 2808920 42728 0 0 228 0 284 2042 85 11 5 2 0 0 36424 3112924 42416 76 5004 288 5260 385 948 84 11 6 4 0 0 36424 2816940 42016 0 0 100 0 223 1252 94 3 3 3 0 0 36424 2812944 41472 0 0 0 0 229 1392 92 8 0 3 0 0 36424 2812948 41112 0 068 0 264 1107 95 3 2 1 0 0 36424 2932948 40756 0 0 0 0 262 879 92 8 0 2 0 0 36424 2808952 40740 0 0 0 0 191 2244 36 12 53 4 0 0 36424 2808952 40504 32 032 0 242 975 93 6 2 2 0 0 36424 3252956 40008 0 064 0 249 2505 85 15 0 3 0 0 36424 2972956 39996 0 0 8 0 127 1419 88 10 2 3 0 0 36424 2988956 39108 0 020 0 247 1632 83 17 0 2 0 0 36424 3332964 38496 0 0 176 0 218 955 91 9 0 3 0 0 36424 3180964 38724 120 0 232 0 112 3026 89 11 0 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 4 0 0 36424 3020968 38800 64 064 0 158 2008 87 13 1 3 0 0 36424 2808936 38192 0 0 192 552 232 678 90 6 4 2 0 0 36424 2988936 37632 0 0 0 4 167 678 98 2 0 2 0 0 36424 2868940 37592 0 0 4 104 177 1137 93 7 0 3 0 0 36396 2852940 37592 0 0 020 185 1125 93 7 0 4 0 0 36396 2848984 37624 0 06064 193 1245 92 8 0 5 0 0 36396 2244 1000 37656 0 028 176 161 2377 69 31 0 1 0 0 36396 2364 1004 37660 0 0 8 244 180 1836 75 25 0 1 0 1 36396 2484 1004 37780 100 0 104 248 178 2369 61 38 1 4 0 1 36384 2020 1012 38328 520 0 560 148 185 1696 58 19 22 6 0 0 45940 1744 1012 47676 108 724 368 868 6886 186930 1 99 0 2 0 1 45856 2528 1028 46480 272 5480 752 5524 264 2413 82 18 0 5 0 0 46072 2732 1028 45740 0 6636 8 6636 297 1165 84 16 0 4 0 0 46072 2532 1028 45776 0 020 4 245 3310 88 13 0 3 0 0 46072 2392 1040 45336 0 024 0 119 1296 91 9 0 2 0 0 46072 2832 1052 44872 0 048 4 113 1276 91 9 0 3 0 0 46072 2392 1056 44544 0 0 0 0 104 943 97 3 0 2 0 0 46068 2808 1056 44112 1104 0 1164 0 144 870 70 11 19 1 0 0 46052
Re: Linux 2.4.5-ac15
On Sun, 17 Jun 2001, Walter Hofmann wrote: > I had already two crashes with ac15. The system was still ping-able, but > login over the network didn't work anymore. > > The first crash happened after I started xosview and noticed that the > system almost used up the swap (for no apparent reason). The second > crash happened shortly after I started fsck on a crypto-loop device. > > This does not happen with ac14, even under heavy load. > > I noticed a second problem: Sometimes the system hangs completely for > approximately ten seconds, but continues just fine after that. I have > seen this with ac14 and ac15, but not with ac12. FWIW, here is the vmstat output for the second (short) hang. Taken with ac14, vmstat 1 was started (long) before the hang and interrupted about five seconds after it. The machine has 128MB RAM and 256MB swap. procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 1 1 0 77332 1584 15632 67740 44 0 448 0 496 932 84 15 1 1 2 0 77456 1848 15944 66960 0 0 372 724 625 2296 62 20 18 3 0 1 77456 1780 16208 67044 72 0 33680 584 1695 20 20 61 2 0 0 77404 1464 16672 66652 0 0 572 0 530 2649 26 19 55 3 1 0 77344 1464 17000 66480 124 0 656 0 419 879 12 16 72 0 3 0 77344 1468 17076 66388 184 0 1080 0 561 654 8 8 84 0 5 0 77892 1464 17184 66892 176 128 800 396 415 1050 14 11 74 0 5 0 77892 1600 17216 66868 16 068 1020 508 295 5 5 90 0 3 0 77892 1464 17316 66784 56 0 37268 464 1287 22 14 64 2 3 0 77892 1464 17524 66828 76 0 440 0 398 987 8 12 79 1 3 0 77892 1464 17780 66680 32 0 512 0 367 1061 10 10 79 1 1 0 77880 1464 18020 66392 224 0 756 0 394 1579 43 12 44 2 1 0 77784 2172 18324 64820 16 0 992 0 529 1745 37 19 44 0 4 0 77936 1848 18428 65180 124 0 252 920 570 451 23 9 69 0 2 0 77888 1680 18564 65656 84 0 744 0 532 721 21 12 67 3 0 0 77876 1464 18700 65564 4 0 1176 0 487 804 26 16 58 0 3 1 77496 1468 18712 65700 424 100 1296 384 401 532 70 10 20 2 0 0 77920 1508 18804 65504 72 248 968 260 525 709 40 9 51 2 2 0 77908 1728 18788 65388 0 120 1000 568 568 608 41 8 51 0 4 0 77908 1620 18828 65548 0 0 172 356 545 420 22 8 69 1 1 0 77904 1712 18472 65464 36 0 1600 0 485 621 52 15 33 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 1 0 78124 1528 18496 64940 116 20 884 288 545 604 54 16 30 4 0 0 78124 1468 18548 64260 4 0 468 0 449 663 49 6 46 3 0 0 77844 3416 18492 63932 100 0 304 0 431 1915 80 16 4 1 2 0 77844 2892 18536 64204 60 0 284 820 583 917 64 13 23 1 0 0 77844 2824 18544 64236 0 04068 591 550 36 6 58 3 0 0 77844 2604 18568 64372 0 0 120 0 455 474 64 13 23 1 0 0 77844 2472 18572 64440 0 056 0 399 617 35 9 56 1 0 0 77844 2456 18572 64460 0 0 0 0 515 721 8 6 87 0 0 0 77844 2448 18572 64468 0 0 4 0 469 655 8 8 83 1 0 0 77844 2384 18572 64528 0 0 0 428 538 641 7 10 83 0 0 0 77844 2388 18572 64528 0 0 0 0 492 733 3 9 89 0 0 0 77844 2368 18572 64548 0 0 0 0 520 804 11 7 82 0 0 0 77844 2336 18572 64580 0 0 0 0 473 680 6 6 89 1 0 0 77844 2276 18584 64608 0 012 0 490 966 30 13 56 2 0 0 77844 2228 18584 64648 0 0 0 344 539 589 47 7 47 3 0 0 77844 2228 18588 64692 0 0 4 0 381 455 29 11 60 2 0 1 77844 2180 18588 64700 0 0 0 0 453 781 33 9 58 1 0 0 77844 2160 18604 64708 0 016 0 390 852 18 5 77 2 0 1 77844 1940 18616 64912 124 0 212 0 318 756 40 8 52 3 0 0 77844 1680 18620 65180 240 0 244 576 492 1632 87 13 0 2 0 1 77844 1528 18540 65540 584 0 592 0 352 2466 90 10 0 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 0 0 77844 1800 18516 65588 40 040 0 357 675 89 11 0 3 5 2 77844 1464 18536 65916 1508 44 1660 264 435 852 37 16 47 1 0 0 77844 1484 18532 65968 864 0 936 0 386 667 89 7 5 1 0 1 77844 146
Re: Linux 2.4.5-ac15
On Sun, 17 Jun 2001, Walter Hofmann wrote: > I had already two crashes with ac15. The system was still ping-able, but > login over the network didn't work anymore. > > The first crash happened after I started xosview and noticed that the > system almost used up the swap (for no apparent reason). The second > crash happened shortly after I started fsck on a crypto-loop device. > > This does not happen with ac14, even under heavy load. I had a hang with ac14 now, too. It hung when I tried to close a browser window after reading the text in it for quite some time. No swapping was going on. Walter - 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: Linux 2.4.5-ac15
I had already two crashes with ac15. The system was still ping-able, but login over the network didn't work anymore. The first crash happened after I started xosview and noticed that the system almost used up the swap (for no apparent reason). The second crash happened shortly after I started fsck on a crypto-loop device. This does not happen with ac14, even under heavy load. I noticed a second problem: Sometimes the system hangs completely for approximately ten seconds, but continues just fine after that. I have seen this with ac14 and ac15, but not with ac12. This is a mixed IDE/SCSI (Adaptec) system, 128MB RAM/256MB swap on a Gigabyte 440LX mainboard with a Pentium II. Walter - 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/
oops with 2.4.5-ac12
I got the following oops with 2.4.5-ac12 after I issued "rmmod -a" twice. I only notices the oops after I issued "rmmod -a" once which might explan that ksymoops cannot name the module which caused the oops. This is possibly ALSA-related (although I never had problems with unloading alsa modules befode). Walter WARNING: This version of ksymoops is obsolete. WARNING: The current version can be obtained from ftp://ftp.ocs.com.au/pub/ksymoops Options used: -V (default) -o /lib/modules/2.4.5-ac12/ (default) -k /proc/ksyms (default) -l /proc/modules (default) -m /usr/src/linux/System.map (default) -c 1 (default) 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. Unable to handle kernel paging request at virtual address c8d92ae0 c017f7de *pde = 012db067 Oops: 0002 CPU:0 EIP:0010:[] EFLAGS: 00010202 eax: c01fc810 ebx: c8dc89dc ecx: c01f6338 edx: c8d92ae0 esi: c8dc7d60 edi: c8dc89c0 ebp: c8dc88dc esp: c4c6ff78 ds: 0018 es: 0018 ss: 0018 Process rmmod (pid: 14454, stackpage=c4c6f000) Stack: c8dc89dc 0008 c8dc30dc c8dc7d60 c8dbe000 c8dbe000 0001 bfffe044 c0116e07 c8dbe000 c8db6000 0001 c0116332 c8dbe000 0001 c4c6e000 08059a14 0061 c0106af3 0028 08059a14 0061 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 89 02 8b 1d 08 c8 1f c0 81 fb 08 c8 1f c0 74 25 89 f6 39 73 >>EIP: c017f7de Trace: c8dc89dc Trace: c8dc30dc Trace: c8dc7d60 Trace: c8dbe000 Trace: c8dbe000 Trace: c0116e07 Code: c017f7de <_EIP>: <=== Code: c017f7de 0:89 02 movl %eax,(%edx) <=== Code: c017f7e0 2:8b 1d 08 c8 1f c0 movl 0xc01fc808,%ebx Code: c017f7e6 8:81 fb 08 c8 1f c0 cmpl $0xc01fc808,%ebx Code: c017f7ec e:74 25 je c017f813 Code: c017f7ee 10:89 f6 movl %esi,%esi Code: c017f7f0 12:39 73 00cmpl %esi,0x0(%ebx) 95 warnings and 12 errors issued. Results may not be reliable. /proc/pci: PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Corporation 440LX/EX - 82443LX/EX Host bridge (rev 3). Master Capable. Latency=32. Prefetchable 32 bit memory at 0xe000 [0xe3ff]. Bus 0, device 1, function 0: PCI bridge: Intel Corporation 440LX/EX - 82443LX/EX AGP bridge (rev 3). Master Capable. Latency=64. Min Gnt=11. Bus 0, device 7, function 0: ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 1). Bus 0, device 7, function 1: IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=32. I/O at 0xf000 [0xf00f]. Bus 0, device 7, function 2: USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1). IRQ 15. Master Capable. Latency=32. I/O at 0x6e00 [0x6e1f]. Bus 0, device 7, function 3: Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 1). IRQ 9. Bus 0, device 9, function 0: Multimedia audio controller: S3 Inc. SonicVibes (rev 0). IRQ 11. Master Capable. Latency=32. I/O at 0x6800 [0x680f]. I/O at 0x6900 [0x690f]. I/O at 0x6a00 [0x6a03]. I/O at 0x6b00 [0x6b03]. I/O at 0x6c00 [0x6c07]. Bus 0, device 10, function 0: Ethernet controller: Winbond Electronics Corp W89C940 (rev 0). IRQ 9. I/O at 0x6d00 [0x6d1f]. Bus 0, device 12, function 0: SCSI storage controller: Adaptec AIC-7880U (rev 0). IRQ 9. Master Capable. Latency=32. Min Gnt=8.Max Lat=8. I/O at 0x6400 [0x64ff]. Non-prefetchable 32 bit memory at 0xe400 [0xe4000fff]. Bus 1, device 0, function 0: VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] AGP (rev 0). IRQ 9. Master Capable. Latency=128. Prefetchable 32 bit memory at 0xa800 [0xa8ff]. Non-prefetchable 32 bit memory at 0xd880 [0xd8803fff]. Non-prefetchable 32 bit memory at 0xd800 [0xd87f]. - 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: Disturbing news..
On Wed, 28 Mar 2001, Jesse Pollard wrote: > By itself it doesn't - but if you also don't have user/group/world rw and > don't own the file, you can't do anything to it. This is all completely useless. Why not remove world rw permissions in the first place. If the admin isn't even able to write a cron job that does this, all help is lost. > It's only there to reduce accidents. If you want to go full out, > remove the symbols from the file. Just as useless. > Now, if ELF were to be modified, I'd just add a segment checksum > for each segment, then put the checksum in the ELF header as well as > in the/a segment header just to make things harder. At exec time a checksum > verify could (expensive) be done on each segment. A reduced level could be > done only on the data segment or text segment. This would at least force > the virus to completly read the file to regenerate the checksum. So? The virus will just redo the checksum. Sooner or later their will be a routine to do this in libbfd and this all reduces to a single additional line of code. > That change would even allow for signature checks of the checksum if the > signature was stored somewhere else (system binaries/setuid binaries...). > But only in a high risk environment. This could even be used for a scanner > to detect ANY change to binaries (and fast too - signature check of checksums > wouldn't require reading the entire file). One sane way to do this is to store the sig on a ro medium and make the kernel check the sig of every binary before it is run. HOWEVER, this means no compilers will work, and you have to delete all script languages like perl or python (or make all of them check the signature). Useless again, IMO. > In any case, the problem is limited to one user, even if nothing is done. Your best bet is to educate your users. Walter - 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: Disturbing news..
On Wed, 28 Mar 2001, Jesse Pollard wrote: > >Any idea? > > Sure - very simple. If the execute bit is set on a file, don't allow > ANY write to the file. This does modify the permission bits slightly > but I don't think it is an unreasonable thing to have. And how exactly does this help? fchmod (fd, 0666); fwrite (fd, ...); fchmod (fd, 0777); Walter - 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: eject weirdness on NEC disc changer, kernel 2.4.2
On Mon, 05 Mar 2001, Jim Breton wrote: > I have had a similar problem in the past where, for example, after > cancelling a burn session with cdrecord I am unable to eject the disc. > However that was on kernel 2.2.x and using "real" scsi (not ide-scsi). This was a bug in cdrecord which used generic scsi access to lock the drive. The kernel cannot notice this. AFAIK this bug is fixed in cdrecord. Walter - 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: 2.2.18/ext2: special file corruption?
Ulrich Windl schrieb am Montag, den 26. Februar 2001: > I had an interesting effect: Due to NVdriver I had a lot of system > freezes, and I had to reboot. Using e2fsck 1.19a (SuSE 7.1) I got the > message that one specific "Special (device/socket/fifo) inode .. has > non-zero size. FIXED." I see them too on every fsck (after a crash). I'm using e2fsck 1.19 (but not from SuSE. The rpm was built on snap.thunk.org, but I can't remember where I got it from). Walter - 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: Announcement: TUX 2.0
On Wed, 31 Jan 2001, Michael K. Johnson wrote: > > TUX 2.0 is now available for download at the following URL: > > ftp://ftp.redhat.com/pub/redhat/tux/tux-2.0/ According to http://www.spec.org/osg/web99/results/: On a PowerEdge 8450/700 8 CPUs: TUX 1.0: 6387 TUX 2.0: 7500 Looks like a remarkable boost! Walter - 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: NT soon to surpass Linux in specweb99 performance?
On Thu, 01 Feb 2001, Gregory Maxwell wrote: > Looks like TUX caught MS's attention: > http://www.spec.org/osg/web99/results/res2000q4/web99-20001211-00082.html > > Anyone know if their method of achieveing this is as flexible as TUX, or is > their "SWC 3.0" simply mean 'spec web cheat' and involve implimenting the > specweb dyanmic stuff in x86 assembly in their microkernel? :) SWC = Scaleable Web Cache http://www.microsoft.com/technet/iis/swc2.asp has more information about SWC 2.0. Microsoft published SpecWeb96 results for IIS+SWC 2.0, but not for SpecWeb99. I would guess that SWC 2.0 didn't help performance for dynamic content. Looks like they fixed this with SWC 3.0. Walter - 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: RTC hardware clock option
On Tue, 30 Jan 2001, Antonio Miguel Trindade wrote: > I just would like to ask all of you what has the option "RTC stores time in > GMT" have to do with APM... The hardware clock in my machine stores time in > GMT, but I do not want APM, so why do I have to have APM just to have that > option enabled... > > Perhaps the intention is to remove that depency, but it has not been done out > of lazyness... (no pun intended, Linus). There is no dependency: APM needs to know this to restore the clock after returning from stand-by. Without APM there is no need to know this (for the kernel). You can still run your hardware clock with GMT. Walter - 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: ECN: Clearing the air
On Sun, 28 Jan 2001, Pavel Machek wrote: > Does not that mean that Linux 2.0.10 mistakenly announces it is ECN > capable when offered ECN connection? No, the RFC deals with this. Walter - 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: ECN and other sites
On Thu, 25 Jan 2001, Michael B. Trausch wrote: > > I've kinda been watching the ECN discussion there, and I have 2.4.0 and > noticed that after I'd installed it, I couldn't get to my favorite search > engine (Dogpile.com). I'd assume they don't support it either, because > when I "echo 0 > /proc/sys/net/ipv4/tcp_ecn" then it goes away. I > notified them about the problem and pointed them to a few webpages with > information and links regarding ECN. Has anyone a compiled list of patches for all the firewalls that block ECN suitable to mail them to the firewall administrators? Walter - 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.org verification key updated
I cannot verify this signature with gpg or pgp. gpg says gpg: invalid radix64 character 00 skipped gpg: Signature made Tue Oct 10 08:26:46 2000 MEST using DSA key ID 2BCBC621 gpg: BAD signature from "H. Peter Anvin (hpa) <[EMAIL PROTECTED]>" Walter -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I just wanted to let everyone know that we have changed the cryptographic key for the Linux Kernel Archives. The reason is that the original key was generated with an expiration date, and unfortunately it appears that too much software out there doesn't support changing the expiration date on an already valid key (the ability to do that, arguably, makes the expiration date useless anyway.) Therefore, we have revoked key 1E1A8782 generated 1999-10-15 and replaced it with key 517D0F0E generated 2000-10-10. Please see http://www.kernel.org/signature.html for more information. The archive machine is currently in process of generating new signature files; they should be distributed to mirrors shortly thereafter in normal order. -hpa - -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE54ramfZ3uzivLxiERAnw7AJ4mNH5RUMz/OGtfCIY0qVNE9ETFggCeOfPo IInpWMaytVNCW1vqWMRG+50= =zatN -END PGP SIGNATURE- - 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/
