* [BENCHMARK] not so good performance of 2.5.52 on TIO bench
From: Aniruddha M Marathe @ 2002-12-16 6:44 UTC (permalink / raw)
To: linux-kernel
Hi,
Here are the results of comparison of kernel 2.5.51 and 2.5.52 on TIObench.
key findings.
-------------------------------------------------------------
test 2.5.52 (as compared to
2.5.51) APPRXIMATE % change
-------------------------------------------------------------
rate (megabytes per second) 5% decrease
CPU % utilization 5% decrease
Average Latency less than 2% increase
Maximum latency 15 % increase
CPU efficiency less than 2% increase
-------------------------------------------------------------
-------------------------------------------------------------
Linux kernel 2.5.52
TIO bench results
Date 16th december 2002
-------------------------------------------------------------
Unit information
================
File size = megabytes
Blk Size = bytes
Rate = megabytes per second
CPU% = percentage of CPU used during the test
Latency = milliseconds
Lat% = percent of requests that took longer than X seconds
CPU Eff = Rate divided by CPU% - throughput per cpu load
Sequential Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.52 252 4096 10 8.48 5.251% 12.152 1825.07 0.00000 0.00000 161
Random Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.52 252 4096 10 0.50 0.729% 211.130 1079.20 0.00000 0.00000 69
Sequential Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.52 252 4096 10 16.17 30.00% 4.525 29226.70 0.06094 0.00625 54
Random Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.52 252 4096 10 0.78 1.084% 0.675 992.39 0.00000 0.00000 72
regards,
Aniruddha Marathe
WIPRO Technologies, India
aniruddha.marathe@wipro.com
^ permalink raw reply
* Re: JDIRTY JWAIT errors in 2.4.19
From: Tupshin Harper @ 2002-12-16 6:37 UTC (permalink / raw)
To: Oleg Drokin; +Cc: linux-kernel
In-Reply-To: <20021214135550.A13549@namesys.com>
[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]
Oleg Drokin wrote:
>Hello!
>
>On Sat, Dec 14, 2002 at 01:29:19AM -0800, Tupshin Harper wrote:
>
>
>
>>i'm getting the following error logged every 11 seconds or so:
>>
>>Dec 14 01:00:49 phylum kernel: vs-3050: wait_buffer_until_released: nobody
>>releases buffer (dev 16:01, size 4096, blocknr 2916352, count 3, list 0,
>>state
>>0x10019, page c1172108, (UPTODATE, CLEAN, UNLOCKED)). Still waiting
>>(-1320000000) JDIRTY !JWAIT
>>Also, some processes are blocking, include ps (so I can't get a complete
>>process list), and shutdown.
>>
>>
>
>Can you please execute SysRq-T, decode it with ksymoops and send us the result?
>
>
I have succeeded in reproducing this problem at will (and
deterministically) with a SysRq enabled kernel.
I can reproduce the problem consistently by doing a cp -av of a
directory(haven't tried other cp permutations, guessing it wouldn't make
a difference) containing three mp3 files from one location on a
partition to another location on the same reiserfs partition. During the
third file, cp hangs(continues to use 80%+ of the CPU), and is
unkillable. A few minutes later, it starts generating the same JDIRTY
error messages that I reported before.
The attached file is a ksymoops processed version of SysRq-T after this
problem has started to occur. There is one cp taking place which is the
one that triggered the problem, and there is also a sync command that is
blocking as well which I tried to do after the cp hung.
I have not tried to do any kind of reiserfs check or repair on the
filesystem, and I can trigger this problem at any point if you would
like me to test further.
-Tupshin
[-- Attachment #2: ksymout.txt --]
[-- Type: text/plain, Size: 30243 bytes --]
ksymoops 2.4.6 on i686 2.4.19-sysrq. Options used
-V (default)
-k /proc/ksyms (specified)
-l /proc/modules (specified)
-o /lib/modules/2.4.19-sysrq/ (specified)
-m /boot/System.map-2.4.19-sysrq (specified)
Dec 15 12:08:30 phylum kernel: init S C12F5F28 4500 1 0 1135 (NOTLB)
Using defaults from ksymoops -t elf32-i386 -a i386
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: keventd S C12D8000 6152 2 1 3 (L-TLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [context_thread+253/424] [kernel_thread+40/56]
Dec 15 12:08:30 phylum kernel: ksoftirqd_CPU S C12D4000 6388 3 1 4 2 (L-TLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [ksoftirqd+116/180] [kernel_thread+40/56]
Dec 15 12:08:30 phylum kernel: kswapd S C12D2000 6108 4 1 5 3 (L-TLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [kswapd+127/196] [kernel_thread+40/56]
Dec 15 12:08:30 phylum kernel: bdflush S 00000282 6560 5 1 6 4 (L-TLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [interruptible_sleep_on+61/80] [bdflush+166/168] [kernel_thread+40/56]
Dec 15 12:08:30 phylum kernel: kupdated D 00000282 5664 6 1 9 5 (L-TLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sleep_on+61/80] [check_journal_end+294/556] [do_journal_end+178/2584] [flush_old_commits+267/304] [flush_old_commits+281/304]
Dec 15 12:08:30 phylum kernel: mdrecoveryd S C138C000 6580 9 1 8 6 (L-TLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [md_thread+201/316] [kernel_thread+40/56]
Dec 15 12:08:30 phylum kernel: khubd S C139DFDC 6000 8 1 10 9 (L-TLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [usb_hub_thread+127/168] [kernel_thread+40/56]
Dec 15 12:08:30 phylum kernel: kreiserfsd S CA33DFB0 6064 10 1 24 8 (L-TLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [interruptible_sleep_on_timeout+66/92] [reiserfs_journal_commit_thread+153/208] [kernel_thread+40/56]
Dec 15 12:08:30 phylum kernel: devfsd S C9DB4000 5964 24 1 206 10 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [devfsd_read+238/868] [sys_read+152/244] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: portmap S 7FFFFFFF 0 206 1 328 24 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_poll+117/204] [do_poll+168/204] [sys_poll+473/748] [sys_socketcall+383/408]
Dec 15 12:08:30 phylum kernel: syslogd S 7FFFFFFF 4752 328 1 331 206 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: klogd R C455C000 4752 331 1 339 328 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [do_syslog+208/776] [kmsg_read+18/24] [sys_read+152/244] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: named S C42A9FAC 5408 339 1 340 361 331 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sys_rt_sigsuspend+238/264] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: named S CA16FF28 1248 340 339 343 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_poll+168/204] [sys_poll+473/748] [do_softirq+75/160]
Dec 15 12:08:30 phylum kernel: named S C4645FAC 0 341 340 342 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sys_rt_sigsuspend+238/264] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: named S CA1F9F88 0 342 340 343 341 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [sys_nanosleep+268/388] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: named S 7FFFFFFF 0 343 340 342 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: slapd S C3E97FAC 4752 361 1 364 366 339 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sys_rt_sigsuspend+238/264] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: slapd S C3E09F28 6292 364 361 365 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_poll+168/204] [sys_poll+473/748] [schedule+714/756]
Dec 15 12:08:30 phylum kernel: slapd S 7FFFFFFF 2660 365 364 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: spamd S 7FFFFFFF 4752 366 1 517 361 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: proxytest S C2A07F88 5172 517 1 525 366 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [sys_nanosleep+268/388] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: authdaemond.p S C29C1F28 1024 525 1 531 538 517 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: authdaemond.p S C299BF28 6332 526 525 527 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: authdaemond.p S C2993F28 6332 527 525 528 526 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: authdaemond.p S C298BF28 6332 528 525 529 527 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: authdaemond.p S C2983F28 6332 529 525 531 528 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: authdaemond.p S C2979F28 6392 531 525 529 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: couriertcpd S 7FFFFFFF 4 538 1 542 525 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: courierlogger S C29CA000 0 542 1 552 538 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [pipe_wait+121/164] [pipe_read+191/544] [sys_read+152/244] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: couriertcpd S 7FFFFFFF 0 552 1 555 542 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: courierlogger S C456A000 0 555 1 559 552 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [pipe_wait+121/164] [pipe_read+191/544] [sys_read+152/244] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: cupsd S C2863F28 4752 559 1 783 555 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: dhcpd S 7FFFFFFF 2656 783 1 793 559 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: inetd S 7FFFFFFF 104 793 1 811 783 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: safe_mysqld S 00000000 2656 811 1 843 870 793 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sys_wait4+860/908] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: mysqld S 7FFFFFFF 0 843 811 844 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: mysqld S C1967F28 6292 844 843 846 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_poll+168/204] [sys_poll+473/748] [sys_wait4+896/908]
Dec 15 12:08:30 phylum kernel: mysqld S C1963FAC 4752 845 844 846 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sys_rt_sigsuspend+238/264] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: mysqld S C18F3FAC 6600 846 844 845 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sys_rt_sigsuspend+238/264] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: netsaint S C1871F88 0 870 1 916 811 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [sys_nanosleep+268/388] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: pptpd S 7FFFFFFF 0 916 1 919 870 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: privoxy S 7FFFFFFF 0 919 1 924 916 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: qmail-send S C168DF28 4600 924 1 934 929 919 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: tcpserver S 7FFFFFFF 4600 928 1 936 929 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: splogger S C1656000 160 929 1 928 924 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [pipe_wait+121/164] [pipe_read+191/544] [sys_read+152/244] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: splogger S C164A000 0 931 924 932 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [pipe_wait+121/164] [pipe_read+191/544] [sys_read+152/244] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: qmail-lspawn S 7FFFFFFF 2532 932 924 933 931 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: qmail-rspawn S 7FFFFFFF 0 933 924 934 932 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: qmail-clean S C1688000 0 934 924 933 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [pipe_wait+121/164] [pipe_read+191/544] [sys_read+152/244] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: rebootmgr S 7FFFFFFF 4600 936 1 949 928 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [free_page_and_swap_cache+53/60] [schedule_timeout+23/148] [do_select+30/468] [do_select+412/468] [sys_select+800/1100]
Dec 15 12:08:30 phylum kernel: nmbd S C0DEFF28 4584 949 1 951 936 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: smbd S 7FFFFFFF 5076 951 1 954 949 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: slpd S 7FFFFFFF 6068 954 1 957 951 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: smartd S C09C3F88 5680 957 1 966 954 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [sys_nanosleep+268/388] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: sshd S 7FFFFFFF 2656 966 1 1327 991 957 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: rpc.statd S 7FFFFFFF 2656 991 1 995 966 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: ntpd S 7FFFFFFF 4692 995 1 1005 1001 991 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: rpc.nfsd S 7FFFFFFF 0 1001 1 1007 995 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_poll+117/204] [do_poll+168/204] [sys_poll+473/748] [sys_sigreturn+182/224]
Dec 15 12:08:30 phylum kernel: ntpd S CBD67FAC 0 1005 995 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sys_rt_sigsuspend+238/264] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: rpc.mountd S 7FFFFFFF 0 1007 1 1026 1001 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_poll+117/204] [do_poll+168/204] [sys_poll+473/748] [sys_sigreturn+182/224]
Dec 15 12:08:30 phylum kernel: squid S 00000000 0 1026 1 1031 1052 1007 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sys_wait4+860/908] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: squid S CBC55F28 0 1031 1026 1043 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_poll+168/204] [sys_poll+473/748] [filp_close+89/104]
Dec 15 12:08:30 phylum kernel: squid_redirec S 7FFFFFFF 2656 1036 1031 1039 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [tcp_data_wait+212/304] [tcp_recvmsg+1060/1956] [lru_cache_del+8/24] [inet_recvmsg+58/84]
Dec 15 12:08:30 phylum kernel: squid_redirec S 7FFFFFFF 2656 1039 1031 1040 1036 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [tcp_data_wait+212/304] [tcp_recvmsg+1060/1956] [lru_cache_del+8/24] [inet_recvmsg+58/84]
Dec 15 12:08:30 phylum kernel: squid_redirec S 7FFFFFFF 2656 1040 1031 1041 1039 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [tcp_data_wait+212/304] [tcp_recvmsg+1060/1956] [lru_cache_del+8/24] [inet_recvmsg+58/84]
Dec 15 12:08:30 phylum kernel: squid_redirec S 7FFFFFFF 0 1041 1031 1042 1040 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [tcp_data_wait+212/304] [tcp_recvmsg+1060/1956] [lru_cache_del+8/24] [inet_recvmsg+58/84]
Dec 15 12:08:30 phylum kernel: squid_redirec S 7FFFFFFF 2656 1042 1031 1043 1041 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [tcp_data_wait+212/304] [tcp_recvmsg+1060/1956] [lru_cache_del+8/24] [inet_recvmsg+58/84]
Dec 15 12:08:30 phylum kernel: unlinkd S CB808000 0 1043 1031 1042 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [pipe_wait+121/164] [pipe_read+191/544] [sys_read+152/244] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: proftpd S CB559F28 0 1052 1 1062 1026 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: usb_perms S CB42BF88 0 1062 1 1066 1052 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [sys_nanosleep+268/388] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: atd S CB0E7F88 152 1066 1 1069 1062 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [sys_nanosleep+268/388] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: cron S CB02DF88 2656 1069 1 1097 1066 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [sys_nanosleep+268/388] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: apache S C8739F28 0 1097 1 1119 1102 1069 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [generic_file_write+1217/1624] [sys_select+800/1100]
Dec 15 12:08:30 phylum kernel: apache-ssl S C8417F28 8 1102 1 1141 1128 1097 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [do_select+412/468] [generic_file_write+1217/1624] [sys_select+800/1100]
Dec 15 12:08:30 phylum kernel: apache S 7FFFFFFF 0 1103 1097 1105 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: apache S 7FFFFFFF 0 1105 1097 1106 1103 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: apache S 7FFFFFFF 2656 1106 1097 1107 1105 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: apache S 7FFFFFFF 0 1107 1097 1119 1106 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: apache S 7FFFFFFF 0 1119 1097 1107 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: bash S 00000000 4600 1128 1 1175 1129 1102 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sys_wait4+860/908] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: bash S 00000000 0 1129 1 1201 1130 1128 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sys_wait4+860/908] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: bash S 00000000 0 1130 1 1205 1131 1129 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [sys_wait4+860/908] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: getty S 7FFFFFFF 0 1131 1 1132 1130 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [read_chan+834/1644] [tty_read+174/216] [sys_read+152/244] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: getty S 7FFFFFFF 0 1132 1 1135 1131 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [read_chan+834/1644] [tty_read+174/216] [sys_read+152/244] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: getty S 7FFFFFFF 2656 1135 1 1132 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [read_chan+834/1644] [tty_read+174/216] [sys_read+152/244] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: gcache S 7FFFFFFF 0 1136 1102 1137 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_packet+206/320] [skb_recv_datagram+175/204] [unix_accept+73/192] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: apache-ssl S 7FFFFFFF 44 1137 1102 1138 1136 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: apache-ssl S 7FFFFFFF 2656 1138 1102 1139 1137 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: apache-ssl S 7FFFFFFF 2656 1139 1102 1140 1138 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: apache-ssl S 7FFFFFFF 2656 1140 1102 1141 1139 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: apache-ssl S 7FFFFFFF 2656 1141 1102 1140 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [wait_for_connect+205/372] [tcp_accept+137/428] [inet_accept+42/308] [sys_accept+97/252]
Dec 15 12:08:30 phylum kernel: cp R current 0 1175 1128 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule+100/756] [wait_buffer_until_released+174/216] [get_empty_nodes+292/432] [fix_nodes+347/1068] [is_tree_node+71/80]
Dec 15 12:08:30 phylum kernel: sync D CA0CBC44 1632 1201 1129 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [__down+81/152] [__down_failed+11/20] [.text.lock.super+123/237] [fsync_dev+34/52] [sys_sync+10/16]
Dec 15 12:08:30 phylum kernel: tail S C72A1F88 0 1205 1130 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [sys_nanosleep+268/388] [system_call+51/56]
Dec 15 12:08:30 phylum kernel: sshd S 7FFFFFFF 196 1327 966 1328 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [unix_stream_data_wait+168/224] [unix_stream_recvmsg+389/928] [sock_recvmsg+55/168] [sock_read+135/144]
Dec 15 12:08:30 phylum kernel: sshd S 7FFFFFFF 2532 1328 1327 (NOTLB)
Dec 15 12:08:30 phylum kernel: Call Trace: [schedule_timeout+23/148] [do_select+412/468] [sys_select+800/1100] [system_call+51/56]
Warning (Oops_read): Code line not seen, dumping what data is available
Proc; init
>>EIP; c12f5f28 <_end+f838e4/c593a1c> <=====
Proc; keventd
>>EIP; c12d8000 <_end+f659bc/c593a1c> <=====
Proc; ksoftirqd_CPU
>>EIP; c12d4000 <_end+f619bc/c593a1c> <=====
Proc; kswapd
>>EIP; c12d2000 <_end+f5f9bc/c593a1c> <=====
Proc; bdflush
>>EIP; 00000282 Before first symbol <=====
Proc; kupdated
>>EIP; 00000282 Before first symbol <=====
Proc; mdrecoveryd
>>EIP; c138c000 <_end+10199bc/c593a1c> <=====
Proc; khubd
>>EIP; c139dfdc <_end+102b998/c593a1c> <=====
Proc; kreiserfsd
>>EIP; ca33dfb0 <_end+9fcb96c/c593a1c> <=====
Proc; devfsd
>>EIP; c9db4000 <_end+9a419bc/c593a1c> <=====
Proc; portmap
>>EIP; 7fffffff Before first symbol <=====
Proc; syslogd
>>EIP; 7fffffff Before first symbol <=====
Proc; klogd
>>EIP; c455c000 <_end+41e99bc/c593a1c> <=====
Proc; named
>>EIP; c42a9fac <_end+3f37968/c593a1c> <=====
Proc; named
>>EIP; ca16ff28 <_end+9dfd8e4/c593a1c> <=====
Proc; named
>>EIP; c4645fac <_end+42d3968/c593a1c> <=====
Proc; named
>>EIP; ca1f9f88 <_end+9e87944/c593a1c> <=====
Proc; named
>>EIP; 7fffffff Before first symbol <=====
Proc; slapd
>>EIP; c3e97fac <_end+3b25968/c593a1c> <=====
Proc; slapd
>>EIP; c3e09f28 <_end+3a978e4/c593a1c> <=====
Proc; slapd
>>EIP; 7fffffff Before first symbol <=====
Proc; spamd
>>EIP; 7fffffff Before first symbol <=====
Proc; proxytest
>>EIP; c2a07f88 <_end+2695944/c593a1c> <=====
Proc; authdaemond.p
>>EIP; c29c1f28 <_end+264f8e4/c593a1c> <=====
Proc; authdaemond.p
>>EIP; c299bf28 <_end+26298e4/c593a1c> <=====
Proc; authdaemond.p
>>EIP; c2993f28 <_end+26218e4/c593a1c> <=====
Proc; authdaemond.p
>>EIP; c298bf28 <_end+26198e4/c593a1c> <=====
Proc; authdaemond.p
>>EIP; c2983f28 <_end+26118e4/c593a1c> <=====
Proc; authdaemond.p
>>EIP; c2979f28 <_end+26078e4/c593a1c> <=====
Proc; couriertcpd
>>EIP; 7fffffff Before first symbol <=====
Proc; courierlogger
>>EIP; c29ca000 <_end+26579bc/c593a1c> <=====
Proc; couriertcpd
>>EIP; 7fffffff Before first symbol <=====
Proc; courierlogger
>>EIP; c456a000 <_end+41f79bc/c593a1c> <=====
Proc; cupsd
>>EIP; c2863f28 <_end+24f18e4/c593a1c> <=====
Proc; dhcpd
>>EIP; 7fffffff Before first symbol <=====
Proc; inetd
>>EIP; 7fffffff Before first symbol <=====
Proc; safe_mysqld
>>EIP; 00000000 Before first symbol
Proc; mysqld
>>EIP; 7fffffff Before first symbol <=====
Proc; mysqld
>>EIP; c1967f28 <_end+15f58e4/c593a1c> <=====
Proc; mysqld
>>EIP; c1963fac <_end+15f1968/c593a1c> <=====
Proc; mysqld
>>EIP; c18f3fac <_end+1581968/c593a1c> <=====
Proc; netsaint
>>EIP; c1871f88 <_end+14ff944/c593a1c> <=====
Proc; pptpd
>>EIP; 7fffffff Before first symbol <=====
Proc; privoxy
>>EIP; 7fffffff Before first symbol <=====
Proc; qmail-send
>>EIP; c168df28 <_end+131b8e4/c593a1c> <=====
Proc; tcpserver
>>EIP; 7fffffff Before first symbol <=====
Proc; splogger
>>EIP; c1656000 <_end+12e39bc/c593a1c> <=====
Proc; splogger
>>EIP; c164a000 <_end+12d79bc/c593a1c> <=====
Proc; qmail-lspawn
>>EIP; 7fffffff Before first symbol <=====
Proc; qmail-rspawn
>>EIP; 7fffffff Before first symbol <=====
Proc; qmail-clean
>>EIP; c1688000 <_end+13159bc/c593a1c> <=====
Proc; rebootmgr
>>EIP; 7fffffff Before first symbol <=====
Proc; nmbd
>>EIP; c0deff28 <_end+a7d8e4/c593a1c> <=====
Proc; smbd
>>EIP; 7fffffff Before first symbol <=====
Proc; slpd
>>EIP; 7fffffff Before first symbol <=====
Proc; smartd
>>EIP; c09c3f88 <_end+651944/c593a1c> <=====
Proc; sshd
>>EIP; 7fffffff Before first symbol <=====
Proc; rpc.statd
>>EIP; 7fffffff Before first symbol <=====
Proc; ntpd
>>EIP; 7fffffff Before first symbol <=====
Proc; rpc.nfsd
>>EIP; 7fffffff Before first symbol <=====
Proc; ntpd
>>EIP; cbd67fac <_end+b9f5968/c593a1c> <=====
Proc; rpc.mountd
>>EIP; 7fffffff Before first symbol <=====
Proc; squid
>>EIP; 00000000 Before first symbol
Proc; squid
>>EIP; cbc55f28 <_end+b8e38e4/c593a1c> <=====
Proc; squid_redirec
>>EIP; 7fffffff Before first symbol <=====
Proc; squid_redirec
>>EIP; 7fffffff Before first symbol <=====
Proc; squid_redirec
>>EIP; 7fffffff Before first symbol <=====
Proc; squid_redirec
>>EIP; 7fffffff Before first symbol <=====
Proc; squid_redirec
>>EIP; 7fffffff Before first symbol <=====
Proc; unlinkd
>>EIP; cb808000 <_end+b4959bc/c593a1c> <=====
Proc; proftpd
>>EIP; cb559f28 <_end+b1e78e4/c593a1c> <=====
Proc; usb_perms
>>EIP; cb42bf88 <_end+b0b9944/c593a1c> <=====
Proc; atd
>>EIP; cb0e7f88 <_end+ad75944/c593a1c> <=====
Proc; cron
>>EIP; cb02df88 <_end+acbb944/c593a1c> <=====
Proc; apache
>>EIP; c8739f28 <_end+83c78e4/c593a1c> <=====
Proc; apache-ssl
>>EIP; c8417f28 <_end+80a58e4/c593a1c> <=====
Proc; apache
>>EIP; 7fffffff Before first symbol <=====
Proc; apache
>>EIP; 7fffffff Before first symbol <=====
Proc; apache
>>EIP; 7fffffff Before first symbol <=====
Proc; apache
>>EIP; 7fffffff Before first symbol <=====
Proc; apache
>>EIP; 7fffffff Before first symbol <=====
Proc; bash
>>EIP; 00000000 Before first symbol
Proc; bash
>>EIP; 00000000 Before first symbol
Proc; bash
>>EIP; 00000000 Before first symbol
Proc; getty
>>EIP; 7fffffff Before first symbol <=====
Proc; getty
>>EIP; 7fffffff Before first symbol <=====
Proc; getty
>>EIP; 7fffffff Before first symbol <=====
Proc; gcache
>>EIP; 7fffffff Before first symbol <=====
Proc; apache-ssl
>>EIP; 7fffffff Before first symbol <=====
Proc; apache-ssl
>>EIP; 7fffffff Before first symbol <=====
Proc; apache-ssl
>>EIP; 7fffffff Before first symbol <=====
Proc; apache-ssl
>>EIP; 7fffffff Before first symbol <=====
Proc; apache-ssl
>>EIP; 7fffffff Before first symbol <=====
Proc; cp
>>EIP; 0000000c Before first symbol <=====
Proc; sync
>>EIP; ca0cbc44 <_end+9d59600/c593a1c> <=====
Proc; tail
>>EIP; c72a1f88 <_end+6f2f944/c593a1c> <=====
Proc; sshd
>>EIP; 7fffffff Before first symbol <=====
Proc; sshd
>>EIP; 7fffffff Before first symbol <=====
1 warning issued. Results may not be reliable.
^ permalink raw reply
* Re: [PATCH RESEND] memory leak in ndisc_router_discovery
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2002-12-16 6:35 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, davem, kuznet, krkumar
In-Reply-To: <200212121905.gBCJ5hn18058@eng2.beaverton.ibm.com>
In article <200212121905.gBCJ5hn18058@eng2.beaverton.ibm.com> (at Thu, 12 Dec 2002 11:05:43 -0800 (PST)), Krishna Kumar <krkumar@us.ibm.com> says:
> I had sent this earlier, there is a bug in router advertisement handling code,
> where the reference (and memory) to an inet6_dev pointer can get leaked (this
> leak can happen atmost once for each interface on a system which receives
> invalid RA's). Below is the patch against 2.5.51 to fix it.
(It would be called "refcnt leakage," or some thing like that, but anyway)
This seems correct fix. please apply...
> -------------------------------------------------------------------------------
> diff -ruN linux.org/net/ipv6/ndisc.c linux/net/ipv6/ndisc.c
> --- linux.org/net/ipv6/ndisc.c Fri Nov 7 10:02:11 2002
> +++ linux/net/ipv6/ndisc.c Fri Nov 8 14:37:27 2002
> @@ -871,6 +871,7 @@
> }
>
> if (!ndisc_parse_options(opt, optlen, &ndopts)) {
> + in6_dev_put(in6_dev);
> if (net_ratelimit())
> ND_PRINTK2(KERN_WARNING
> "ICMP6 RA: invalid ND option, ignored.\n");
> -------------------------------------------------------------------------------
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply
* [TRIVIAL] remove emacs settings
From: Rusty Trivial Russell @ 2002-12-16 6:26 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-scsi
[ Marcelo: this change seems very popular 8) ]
From: Andries.Brouwer@cwi.nl
--- trivial-2.4.21-pre1/drivers/scsi/scsi_proc.c.orig 2002-12-16 17:22:02.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/scsi/scsi_proc.c 2002-12-16 17:22:02.000000000 +1100
@@ -308,22 +308,3 @@
}
#endif /* CONFIG_PROC_FS */
-
-/*
- * Overrides for Emacs so that we get a uniform tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only. This must remain at the end
- * of the file.
- * ---------------------------------------------------------------------------
- * Local variables:
- * c-indent-level: 4
- * c-brace-imaginary-offset: 0
- * c-brace-offset: -4
- * c-argdecl-indent: 4
- * c-label-offset: -4
- * c-continued-statement-offset: 4
- * c-continued-brace-offset: 0
- * indent-tabs-mode: nil
- * tab-width: 8
- * End:
- */
--
Don't blame me: the Monkey is driving
File: Andries.Brouwer@cwi.nl: [TRIVIAL] remove emacs settings
^ permalink raw reply
* RE: /proc/cpuinfo and hyperthreading
From: Zwane Mwaikambo @ 2002-12-16 6:35 UTC (permalink / raw)
To: Scott Robert Ladd; +Cc: Robert Love, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.50.0212160126110.12535-100000@montezuma.mastecende.com>
On Mon, 16 Dec 2002, Zwane Mwaikambo wrote:
> On Sun, 15 Dec 2002, Scott Robert Ladd wrote:
>
> > But later in the boot, it also states:
> >
> > Dec 15 11:51:18 Tycho kernel: SMP motherboard not detected.
> >
> > Something just doesn't look right about this.
>
> Thats just the MP table parsing code whining. Which is ok since you're
> using ACPI... hmm then again...
>
> if (!smp_found_config) {
> printk(KERN_NOTICE "SMP motherboard not detected.\n");
> smpboot_clear_io_apic_irqs();
> phys_cpu_present_map = 1;
> if (APIC_init_uniprocessor())
Dec 15 14:30:34 Tycho kernel: CPUS done 2
It's ok.
(I feel like Jekyll & Hyde)...
--
function.linuxpower.ca
^ permalink raw reply
* [TRIVIAL] available spell fixes
From: Rusty Trivial Russell @ 2002-12-16 6:23 UTC (permalink / raw)
To: Werner Almesberger, Mitchell Blank, dledford, jgarzik, linux-scsi
Cc: Marcelo Tosatti
From: <alfre@ibd.es>
Against vanilla 2.4.20, spell fixes for 'available'.
Regrads - alfredo
--
Alfredo Sanjuan
<alfre@ibd.es>
--- trivial-2.4.21-pre1/drivers/atm/iphase.c.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/atm/iphase.c 2002-12-16 17:21:59.000000000 +1100
@@ -1884,7 +1884,7 @@
return -EINVAL;
}
if (vcc->qos.txtp.max_pcr > iadev->LineRate) {
- IF_CBR(printk("PCR is not availble\n");)
+ IF_CBR(printk("PCR is not available\n");)
return -1;
}
vc->type = CBR;
@@ -1894,7 +1894,7 @@
}
}
else
- printk("iadev: Non UBR, ABR and CBR traffic not supportedn");
+ printk("iadev: Non UBR, ABR and CBR traffic not supported\n");
iadev->testTable[vcc->vci]->vc_status |= VC_ACTIVE;
IF_EVENT(printk("ia open_tx returning \n");)
--- trivial-2.4.21-pre1/drivers/ieee1394/dv1394.h.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/ieee1394/dv1394.h 2002-12-16 17:21:59.000000000 +1100
@@ -175,7 +175,7 @@
where copy_DV_frame() reads or writes on the dv1394 file descriptor
(read/write mode) or copies data to/from the mmap ringbuffer and
then calls ioctl(DV1394_SUBMIT_FRAMES) to notify dv1394 that new
- frames are availble (mmap mode).
+ frames are available (mmap mode).
reset_dv1394() is called in the event of a buffer
underflow/overflow or a halt in the DV stream (e.g. due to a 1394
--- trivial-2.4.21-pre1/drivers/md/lvm.c.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/md/lvm.c 2002-12-16 17:21:59.000000000 +1100
@@ -2405,7 +2405,7 @@
}
}
- /* save availiable i/o statistic data */
+ /* save available i/o statistic data */
if (old_lv->lv_stripes < 2) { /* linear logical volume */
end = min(old_lv->lv_current_le, new_lv->lv_current_le);
for (l = 0; l < end; l++) {
--- trivial-2.4.21-pre1/drivers/net/saa9730.c.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/net/saa9730.c 2002-12-16 17:21:59.000000000 +1100
@@ -265,7 +265,7 @@
lp->NextRcvPacketIndex = 0;
lp->NextRcvToUseIsA = 1;
- /* Set current buffer index & next availble packet index */
+ /* Set current buffer index & next available packet index */
lp->NextTxmPacketIndex = 0;
lp->NextTxmBufferIndex = 0;
lp->PendingTxmPacketIndex = 0;
@@ -520,7 +520,7 @@
lp->NextRcvPacketIndex = 0;
lp->NextRcvToUseIsA = 1;
- /* Set current buffer index & next availble packet index */
+ /* Set current buffer index & next available packet index */
lp->NextTxmPacketIndex = 0;
lp->NextTxmBufferIndex = 0;
lp->PendingTxmPacketIndex = 0;
--- trivial-2.4.21-pre1/drivers/net/wan/comx-hw-munich.c.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/net/wan/comx-hw-munich.c 2002-12-16 17:21:59.000000000 +1100
@@ -269,7 +269,7 @@
- Path Code Violations >1, but <320
- not a Severely Errored Second
- no AIS
- - not incremented during an Unavailabla Second */
+ - not incremented during an Unavailable Second */
severely_err_secs, /* Severely Errored Second:
- CRC4: >=832 Path COde Violations || >0 Out Of Frame defects
- noCRC4: >=2048 Line Code Violations
--- trivial-2.4.21-pre1/drivers/scsi/aic7xxx/aic7xxx.h.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/scsi/aic7xxx/aic7xxx.h 2002-12-16 17:21:59.000000000 +1100
@@ -362,7 +362,7 @@
/*
* The driver keeps up to MAX_SCB scb structures per card in memory. The SCB
- * consists of a "hardware SCB" mirroring the fields availible on the card
+ * consists of a "hardware SCB" mirroring the fields available on the card
* and additional information the kernel stores for each transaction.
*
* To minimize space utilization, a portion of the hardware scb stores
--- trivial-2.4.21-pre1/drivers/scsi/aic7xxx/aic7xxx_core.c.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/scsi/aic7xxx/aic7xxx_core.c 2002-12-16 17:21:59.000000000 +1100
@@ -388,7 +388,7 @@
ahc_dump_card_state(ahc);
- /* Tell everyone that this HBA is no longer availible */
+ /* Tell everyone that this HBA is no longer available */
ahc_abort_scbs(ahc, CAM_TARGET_WILDCARD, ALL_CHANNELS,
CAM_LUN_WILDCARD, SCB_LIST_NULL, ROLE_UNKNOWN,
CAM_NO_HBA);
@@ -2748,9 +2748,9 @@
targ_scsirate = tinfo->scsirate;
/*
- * Parse as much of the message as is availible,
+ * Parse as much of the message as is available,
* rejecting it if we don't support it. When
- * the entire message is availible and has been
+ * the entire message is available and has been
* handled, return MSGLOOP_MSGCOMPLETE, indicating
* that we have parsed an entire message.
*
--- trivial-2.4.21-pre1/drivers/scsi/aic7xxx_old.c.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/scsi/aic7xxx_old.c 2002-12-16 17:21:59.000000000 +1100
@@ -5435,9 +5435,9 @@
target_mask = (0x01 << tindex);
/*
- * Parse as much of the message as is availible,
+ * Parse as much of the message as is available,
* rejecting it if we don't support it. When
- * the entire message is availible and has been
+ * the entire message is available and has been
* handled, return TRUE indicating that we have
* parsed an entire message.
*/
--- trivial-2.4.21-pre1/drivers/scsi/ips.c.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/scsi/ips.c 2002-12-16 17:21:59.000000000 +1100
@@ -7211,7 +7211,7 @@
/* Assumes that ips_read_adapter_status() is called first filling in */
/* the data for SubSystem Parameters. */
/* Called from ips_write_driver_status() so it also assumes NVRAM Page 5 */
-/* Data is availaible. */
+/* Data is available. */
/* */
/*---------------------------------------------------------------------------*/
static void ips_version_check(ips_ha_t *ha, int intr) {
--- trivial-2.4.21-pre1/drivers/scsi/pcmcia/nsp_cs.c.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/scsi/pcmcia/nsp_cs.c 2002-12-16 17:21:59.000000000 +1100
@@ -707,7 +707,7 @@
ocount += res;
//DEBUG(0, " ptr=0x%p this_residual=0x%x ocount=0x%x\n", SCpnt->SCp.ptr, SCpnt->SCp.this_residual, ocount);
- /* go to next scatter list if availavle */
+ /* go to next scatter list if available */
if (SCpnt->SCp.this_residual == 0 &&
SCpnt->SCp.buffers_residual != 0 ) {
//DEBUG(0, " scatterlist next timeout=%d\n", time_out);
@@ -780,7 +780,7 @@
SCpnt->SCp.this_residual -= res;
ocount += res;
- /* go to next scatter list if availavle */
+ /* go to next scatter list if available */
if (SCpnt->SCp.this_residual == 0 &&
SCpnt->SCp.buffers_residual != 0 ) {
//DEBUG(0, " scatterlist next\n");
--- trivial-2.4.21-pre1/net/ipv6/af_inet6.c.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/net/ipv6/af_inet6.c 2002-12-16 17:21:59.000000000 +1100
@@ -619,7 +619,7 @@
/*
* ipngwg API draft makes clear that the correct semantics
* for TCP and UDP is to consider one TCP and UDP instance
- * in a host availiable by both INET and INET6 APIs and
+ * in a host available by both INET and INET6 APIs and
* able to communicate via both network protocols.
*/
--- trivial-2.4.21-pre1/net/ipv6/ip6_output.c.orig 2002-12-16 17:21:59.000000000 +1100
+++ trivial-2.4.21-pre1/net/ipv6/ip6_output.c 2002-12-16 17:21:59.000000000 +1100
@@ -563,7 +563,7 @@
if (err) {
#if IP6_DEBUG >= 2
printk(KERN_DEBUG "ip6_build_xmit: "
- "no availiable source address\n");
+ "no available source address\n");
#endif
goto out;
}
--
Don't blame me: the Monkey is driving
File: =?ISO-8859-1?Q?Alfredo_Sanju=C3=A1n?= <alfre@ibd.es>: [TRIVIAL] available spell fixes
^ permalink raw reply
* Re: sendmail
From: Ray Olszewski @ 2002-12-16 6:23 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <F4bxgg8DUDEne3Ndrpu0000ba5a@hotmail.com>
I don't know that this is the best place to ask these questions, but it is
at least a plausible place to start. I doubt any of what you need to know
is SuSE specific. I'm afraid I do need a bit of clarification from you to
be able to give you good answers. Details below.
At 04:59 AM 12/16/02 +0000, Veggies Unite! wrote:
>I hope that this is the correct place to e-mail this question - if
>not, I would appreciate being re-directed. I've set up SuSe 8.0 on a
>computer running through a router and a cable modem.
You understand, I trust, that the router will have to be set up to forward
port 25 (SMTP) to the server. Linux routers do this easily, as do all the
other NATing routers I've looked at in recent times. The details will
depend on what router you have, of course.
>I have a
>static IP, and I have a domain name pointing to the IP via a
>Registrar that also handles a POP3 account.
The omitted detail here is the relationship of the POP3 account to the
domain name. Specifially, if the comain is whosis.com, does mail to
anyone@whosis.com get redirected (by way of an MX DNS entry, for example)
to the Registrar's server (and thence to the POP3 account)? Or is the
POP3account in the form of someuserid@someotherdomainname.com ? The first
setup will interfere with incoming mail but the second will not.
>I've set up Majordomo on
>my computer and would like to configure sendmail as a mail server so
>that it will handle mailing lists aliases for Majordomo.
Aside from the details I've mentioned -- port forwarding and a possible
MX-record conflict -- the sendmail part of this is a standard sendmail
configuration. I'd expect SuSE to have an out-of-the-box setup procedure
that handles this. If it doesn't ... what setup options does it give you?
>Also, I
>would need to run a POP server to allow me to receive mail from my
>server instead of the Registar.
Receive it where? Do you have one or more workstations independent of the
server? If so, this too is standard ... just install any of the popular
POP3 servers (I run popa3d on my Debian server; there are several choices,
and SuSE may favor one of the others). Then have the clients look to the
LAN address of the server (assuming they are on the same LAN). If you want
to get mail fro the server to off-LAN clients, the setup is a bit more
involved ... post a followup if that's what you meant.
>In order for the aliases for majordomo to work, do I have cancel my
>mail coming from the POP3 account via the Registrar?
I can't give you an answer here until you explain how the POP3 account
relates to the domain name. If e-mail to either majordomo@whosis.com and to
eachlisname@whosis.com does NOT get redirected to the POP3 account, then it
should have no effect on the server's operation. If it does get redirected,
then it migh still work, if you have the server collect the POP3 mail and
use a glue program like procmail to distribute it to majordomo itself and
to the various majordomo lists.
>Please let me know of any documentation on this or if you have
>specific advice on what I would need to do.
The packages you need to use themselves all come with the usual kinds of
documentation (man pages, Info files, other odds and ends, and often their
own Web sites), and if you are not familiar with the range of HowTos and
similar resources at (for example) www.tldp.org, you shouuld make their
acquaintance. Aside from that, the better approach is for you to describe
particular problems you need help in solving.
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* RE: Compiling iproute2(w/HTB patch) for 2.5.51
From: Mikael Starvik @ 2002-12-16 6:26 UTC (permalink / raw)
To: 'linux-kernel@vger.kernel.org'
I have the exact same problem with sysklogd and I found
that linux/module.h has a lot of new includes in 2.5
that indirectly brings in a lot of .h files that
shouldn't be included from userspace.
Because of this you get both the compilers definition
of FD_SET etc and the kernels version. I have not yet
had the time to find out how to solve this but the
solution is either to remove some includes or to add
more #ifdef __KERNEL__.
Question 1: Should it at all be possible to compile
applications with 2.5.x headers?
Question 2: Is there any chance that we can remove
or #ifdef some includes in module.h (e.g. sched.h)?
/Mikael
^ permalink raw reply
* RE: /proc/cpuinfo and hyperthreading
From: Zwane Mwaikambo @ 2002-12-16 6:28 UTC (permalink / raw)
To: Scott Robert Ladd; +Cc: Robert Love, Linux Kernel Mailing List
In-Reply-To: <FKEAJLBKJCGBDJJIPJLJEEKADLAA.scott@coyotegulch.com>
On Sun, 15 Dec 2002, Scott Robert Ladd wrote:
> But later in the boot, it also states:
>
> Dec 15 11:51:18 Tycho kernel: SMP motherboard not detected.
>
> Something just doesn't look right about this.
Thats just the MP table parsing code whining. Which is ok since you're
using ACPI... hmm then again...
if (!smp_found_config) {
printk(KERN_NOTICE "SMP motherboard not detected.\n");
smpboot_clear_io_apic_irqs();
phys_cpu_present_map = 1;
if (APIC_init_uniprocessor())
--
function.linuxpower.ca
^ permalink raw reply
* Re: ACK packets being dropped from yahoo
From: Joel Newkirk @ 2002-12-16 6:11 UTC (permalink / raw)
To: Jon Wyatt, netfilter
In-Reply-To: <F3EgmgEaIj38y8iUSmR0000d53d@hotmail.com>
On Sunday 15 December 2002 09:50 am, Jon Wyatt wrote:
> It appears that yahoo is sending an ACK which I'm blocking (because
> it's not part of an initialisation), unless I've misunderstood the
> communication process.
>
> Here's the rules where I set them:-
> $IPTABLES -N bad_tcp_packets
> $IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j
> LOG --log-prefix "New not syn:"
> $IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j
> DROP
>
>
>
> And here's the message I get when yahoo attempts to send the ACK.
>
> New not syn:IN=ppp0 OUT= MAC= SRC=212.158.*.* DST=217.135.*.* LEN=52
> TOS=0x00 PREC=0x00 TTL=63 ID=27155 PROTO=TCP SPT=80 DPT=32782
> WINDOW=8760 RES=0x00 ACK RST URGP=0
>
> What's going on there then?
I think the question should be "Why is this NEW?" Dest IP must be
correct for you to get it, and sourceport is as well. Is it coming from
a different IP? Or to a different destport? Or does netfilter think
the connection has closed? Something must be different for the state
machine to consider it NEW. Is this from the firewall machine, or
forwarded through it with SNAT or MASQ?
BTW, when I try this rule as first rule in my INPUT chain, it does NOT
hit when I do a Yahoo search, the search works fine. Is there something
more particular about your search, or is it just "yahoo.com" and enter
some text to search for?
j
^ permalink raw reply
* Re: [parisc-linux] problems with PCI IDE controller
From: John Marvin @ 2002-12-16 6:09 UTC (permalink / raw)
To: parisc-linux
> On Sat, 2002-12-14 at 13:10, Matthew Wilcox wrote:
> > > hp-c240 login: Uniform Multi-Platform E-IDE driver Revision: 6.31
> > > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> > > PDC20268: IDE controller on PCI bus 00 dev 08
> > > PDC20268: chipset revision 2
> > > PDC20268: not 100% native mode: will probe irqs later
>
> Is this a plug in card. For some reason it has been left in non native
> mode so won't work as a plug in board.
I don't think this is a problem. I have a similar card in my home PC, and
it prints the same thing (re: not 100% native mode). Here is an excerpt
from my PC's boot messages running 2.4.19:
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20267: IDE controller on PCI bus 02 dev 08
PCI: Found IRQ 10 for device 02:01.0
PDC20267: chipset revision 2
PDC20267: not 100% native mode: will probe irqs later
PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide0: BM-DMA at 0xa400-0xa407, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xa408-0xa40f, BIOS settings: hdc:pio, hdd:pio
All of my hard drives are on this card, so I know it works just fine (I
use ide=reverse so that my hard drives start with hda. I keep my CD and
DVD drives on the motherboard IDE buses).
John
^ permalink raw reply
* [PATCH] (3/4) stack updates for x86
From: Dave Hansen @ 2002-12-16 5:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 174 bytes --]
C-stack_usage_check-2.5.52+bk-6.patch
Check for stack overflows on entry to each funtion. Use gcc's
-p profiling feature to do it.
--
Dave Hansen
haveblue@us.ibm.com
[-- Attachment #2: C-stack_usage_check-2.5.52+bk6.patch --]
[-- Type: text/plain, Size: 6894 bytes --]
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.860.1.2 -> 1.866
# arch/i386/kernel/process.c 1.32.1.3 -> 1.38
# arch/i386/kernel/irq.c 1.23.1.2 -> 1.26
# Makefile 1.344 -> 1.346
# include/asm-i386/thread_info.h 1.10.1.2 -> 1.14
# arch/i386/Kconfig 1.13 -> 1.15
# arch/i386/kernel/entry.S 1.38.1.6 -> 1.49
# arch/i386/Makefile 1.24.2.7 -> 1.30
# arch/i386/boot/compressed/misc.c 1.9 -> 1.10
# arch/i386/kernel/init_task.c 1.6.1.1 -> 1.8
# arch/i386/kernel/i386_ksyms.c 1.36.2.4 -> 1.41
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/12/15 haveblue@elm3b96.(none) 1.859.1.2
# Merge elm3b96.(none):/work/dave/bk/linux-2.5-thread_info_infra
# into elm3b96.(none):/work/dave/bk/linux-2.5-overflow-detect
# --------------------------------------------
# 02/12/15 haveblue@elm3b96.(none) 1.865
# Merge elm3b96.(none):/work/dave/bk/linux-2.5-irq-stack
# into elm3b96.(none):/work/dave/bk/linux-2.5-irq-stack+overflow-detect
# --------------------------------------------
# 02/12/15 haveblue@elm3b96.(none) 1.866
# Merge elm3b96.(none):/work/dave/bk/linux-2.5-overflow-detect
# into elm3b96.(none):/work/dave/bk/linux-2.5-irq-stack+overflow-detect
# --------------------------------------------
#
diff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig Sun Dec 15 21:16:27 2002
+++ b/arch/i386/Kconfig Sun Dec 15 21:16:27 2002
@@ -1573,6 +1573,25 @@
If you don't debug the kernel, you can say N, but we may not be able
to solve problems without frame pointers.
+config X86_STACK_CHECK
+ bool "Detect stack overflows"
+ depends on FRAME_POINTER
+ help
+ Say Y here to have the kernel attempt to detect when the per-task
+ kernel stack overflows. This is much more robust checking than
+ the above overflow check, which will only occasionally detect
+ an overflow. The level of guarantee here is much greater.
+
+ Some older versions of gcc don't handle the -p option correctly.
+ Kernprof is affected by the same problem, which is described here:
+ http://oss.sgi.com/projects/kernprof/faq.html#Q9
+
+ Basically, if you get oopses in __free_pages_ok during boot when
+ you have this turned on, you need to fix gcc. The Redhat 2.96
+ version and gcc-3.x seem to work.
+
+ If not debugging a stack overflow problem, say N
+
config X86_EXTRA_IRQS
bool
depends on X86_LOCAL_APIC
diff -Nru a/arch/i386/Makefile b/arch/i386/Makefile
--- a/arch/i386/Makefile Sun Dec 15 21:16:27 2002
+++ b/arch/i386/Makefile Sun Dec 15 21:16:27 2002
@@ -52,6 +52,10 @@
MACHINE := mach-generic
endif
+ifdef CONFIG_X86_STACK_CHECK
+CFLAGS += -p
+endif
+
HEAD := arch/i386/kernel/head.o arch/i386/kernel/init_task.o
libs-y += arch/i386/lib/
diff -Nru a/arch/i386/boot/compressed/misc.c b/arch/i386/boot/compressed/misc.c
--- a/arch/i386/boot/compressed/misc.c Sun Dec 15 21:16:27 2002
+++ b/arch/i386/boot/compressed/misc.c Sun Dec 15 21:16:27 2002
@@ -377,3 +377,7 @@
if (high_loaded) close_output_buffer_if_we_run_high(mv);
return high_loaded;
}
+
+/* We don't actually check for stack overflows this early. */
+__asm__(".globl mcount ; mcount: ret\n");
+
diff -Nru a/arch/i386/kernel/entry.S b/arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S Sun Dec 15 21:16:27 2002
+++ b/arch/i386/kernel/entry.S Sun Dec 15 21:16:27 2002
@@ -520,6 +520,61 @@
pushl $do_spurious_interrupt_bug
jmp error_code
+
+#ifdef CONFIG_X86_STACK_CHECK
+.data
+ .globl stack_overflowed
+stack_overflowed:
+ .long 0
+.text
+
+ENTRY(mcount)
+ push %eax
+ movl $(THREAD_SIZE - 1),%eax
+ andl %esp,%eax
+ cmpl $STACK_WARN,%eax /* more than half the stack is used*/
+ jle 1f
+2:
+ popl %eax
+ ret
+1:
+ lock; btsl $0,stack_overflowed
+ jc 2b
+
+ # switch to overflow stack
+ movl %esp,%eax
+ movl $(stack_overflow_stack + THREAD_SIZE - 4),%esp
+
+ pushf
+ cli
+ pushl %eax
+
+ # push eip then esp of error for stack_overflow_panic
+ pushl 4(%eax)
+ pushl %eax
+
+ # update the task pointer and cpu in the overflow stack's thread_info.
+ GET_THREAD_INFO_WITH_ESP(%eax)
+ movl TI_TASK(%eax),%ebx
+ movl %ebx,stack_overflow_stack+TI_TASK
+ movl TI_CPU(%eax),%ebx
+ movl %ebx,stack_overflow_stack+TI_CPU
+
+ call stack_overflow
+
+ # pop off call arguments
+ addl $8,%esp
+
+ popl %eax
+ popf
+ movl %eax,%esp
+ popl %eax
+ movl $0,stack_overflowed
+ ret
+
+#warning stack check enabled
+#endif
+
.data
ENTRY(sys_call_table)
.long sys_restart_syscall /* 0 - old "setup()" system call, used for restarting */
diff -Nru a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c
--- a/arch/i386/kernel/i386_ksyms.c Sun Dec 15 21:16:27 2002
+++ b/arch/i386/kernel/i386_ksyms.c Sun Dec 15 21:16:27 2002
@@ -216,3 +216,8 @@
EXPORT_SYMBOL(edd);
EXPORT_SYMBOL(eddnr);
#endif
+
+#ifdef CONFIG_X86_STACK_CHECK
+extern void mcount(void);
+EXPORT_SYMBOL(mcount);
+#endif
diff -Nru a/arch/i386/kernel/init_task.c b/arch/i386/kernel/init_task.c
--- a/arch/i386/kernel/init_task.c Sun Dec 15 21:16:27 2002
+++ b/arch/i386/kernel/init_task.c Sun Dec 15 21:16:27 2002
@@ -16,6 +16,10 @@
union thread_union init_irq_union
__attribute__((__section__(".data.init_task")));
+#ifdef CONFIG_X86_STACK_CHECK
+union thread_union stack_overflow_stack
+ __attribute__((__section__(".data.init_task")));
+#endif
/*
* Initial thread structure.
diff -Nru a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
--- a/arch/i386/kernel/process.c Sun Dec 15 21:16:27 2002
+++ b/arch/i386/kernel/process.c Sun Dec 15 21:16:27 2002
@@ -158,7 +158,25 @@
__setup("idle=", idle_setup);
-void show_regs(struct pt_regs * regs)
+void stack_overflow(unsigned long esp, unsigned long eip)
+{
+ int panicing = ((esp&(THREAD_SIZE-1)) <= STACK_PANIC);
+
+ printk( "esp: 0x%x masked: 0x%x STACK_PANIC:0x%x %d %d\n",
+ esp, (esp&(THREAD_SIZE-1)), STACK_PANIC, (((esp&(THREAD_SIZE-1)) <= STACK_PANIC)), panicing );
+
+ if (panicing)
+ print_symbol("stack overflow from %s\n", eip);
+ else
+ print_symbol("excessive stack use from %s\n", eip);
+ printk("esp: %p\n", (void*)esp);
+ show_trace((void*)esp);
+
+ if (panicing)
+ panic("stack overflow\n");
+}
+
+asmlinkage void show_regs(struct pt_regs * regs)
{
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
diff -Nru a/include/asm-i386/thread_info.h b/include/asm-i386/thread_info.h
--- a/include/asm-i386/thread_info.h Sun Dec 15 21:16:27 2002
+++ b/include/asm-i386/thread_info.h Sun Dec 15 21:16:27 2002
@@ -63,6 +63,8 @@
*/
#define THREAD_ORDER 1
#define INIT_THREAD_SIZE THREAD_SIZE
+#define STACK_PANIC 0x200ul
+#define STACK_WARN ((THREAD_SIZE)>>1)
#ifndef __ASSEMBLY__
^ permalink raw reply
* [PATCH] (2/4) stack updates for x86
From: Dave Hansen @ 2002-12-16 5:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 122 bytes --]
B-interrupt_stacks-2.5.52+bk-6.patch
Have special stacks for use in interrupts.
--
Dave Hansen
haveblue@us.ibm.com
[-- Attachment #2: B-interrupt_stacks-2.5.52+bk-6.patch --]
[-- Type: text/plain, Size: 7316 bytes --]
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.859.1.1 -> 1.862
# arch/i386/kernel/process.c 1.32.1.5 -> 1.35
# arch/i386/kernel/irq.c 1.21.1.3 -> 1.25
# include/asm-i386/thread_info.h 1.8.1.1 -> 1.12
# arch/i386/kernel/entry.S 1.39.1.4 -> 1.44
# arch/i386/kernel/smpboot.c 1.36.1.4 -> 1.40
# arch/i386/kernel/init_task.c 1.6 -> 1.7
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/12/15 haveblue@elm3b96.(none) 1.862
# Merge elm3b96.(none):/work/dave/bk/linux-2.5-thread_info_infra
# into elm3b96.(none):/work/dave/bk/linux-2.5-irq-stack
# --------------------------------------------
#
diff -Nru a/arch/i386/kernel/entry.S b/arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S Sun Dec 15 20:59:59 2002
+++ b/arch/i386/kernel/entry.S Sun Dec 15 20:59:59 2002
@@ -333,7 +333,45 @@
ALIGN
common_interrupt:
SAVE_ALL
+
+
+ GET_THREAD_INFO(%ebx)
+ movl TI_IRQ_STACK(%ebx),%ecx
+ movl TI_TASK(%ebx),%edx
+ movl %esp,%eax
+ leal (THREAD_SIZE-4)(%ecx),%esi # %ecx+THREAD_SIZE is next stack
+ # -4 keeps us in the right one
+ testl %ecx,%ecx # is there a valid irq_stack?
+
+ # switch to the irq stack
+#ifdef CONFIG_X86_HAVE_CMOV
+ cmovnz %esi,%esp
+#else
+ jz 1f
+ mov %esi,%esp
+1:
+#endif
+
+ # update the task pointer in the irq stack
+ GET_THREAD_INFO(%esi)
+ movl %edx,TI_TASK(%esi)
+
+ # update the preempt count in the irq stack
+ movl TI_PRE_COUNT(%ebx),%ecx
+ movl %ecx,TI_PRE_COUNT(%esi)
+
call do_IRQ
+
+ movl %eax,%esp # potentially restore non-irq stack
+
+ # copy flags from the irq stack back into the task's thread_info
+ # %esi is saved over the do_IRQ call and contains the irq stack
+ # thread_info pointer
+ # %ebx contains the original thread_info pointer
+ movl TI_FLAGS(%esi),%eax
+ movl $0,TI_FLAGS(%esi)
+ LOCK orl %eax,TI_FLAGS(%ebx)
+
jmp ret_from_intr
#define BUILD_INTERRUPT(name, nr) \
diff -Nru a/arch/i386/kernel/init_task.c b/arch/i386/kernel/init_task.c
--- a/arch/i386/kernel/init_task.c Sun Dec 15 20:59:59 2002
+++ b/arch/i386/kernel/init_task.c Sun Dec 15 20:59:59 2002
@@ -13,6 +13,10 @@
static struct signal_struct init_signals = INIT_SIGNALS(init_signals);
struct mm_struct init_mm = INIT_MM(init_mm);
+union thread_union init_irq_union
+ __attribute__((__section__(".data.init_task")));
+
+
/*
* Initial thread structure.
*
diff -Nru a/arch/i386/kernel/irq.c b/arch/i386/kernel/irq.c
--- a/arch/i386/kernel/irq.c Sun Dec 15 20:59:59 2002
+++ b/arch/i386/kernel/irq.c Sun Dec 15 20:59:59 2002
@@ -311,7 +311,8 @@
* SMP cross-CPU interrupts have their own specific
* handlers).
*/
-asmlinkage unsigned int do_IRQ(struct pt_regs regs)
+struct pt_regs *do_IRQ(struct pt_regs *regs) __attribute__((regparm(1)));
+struct pt_regs *do_IRQ(struct pt_regs *regs)
{
/*
* We ack quickly, we don't want the irq controller
@@ -323,7 +324,7 @@
* 0 return value means that this irq is already being
* handled by some other CPU. (or is disabled)
*/
- int irq = regs.orig_eax & 0xff; /* high bits used in ret_from_ code */
+ int irq = regs->orig_eax & 0xff; /* high bits used in ret_from_ code */
int cpu = smp_processor_id();
irq_desc_t *desc = irq_desc + irq;
struct irqaction * action;
@@ -388,7 +389,7 @@
*/
for (;;) {
spin_unlock(&desc->lock);
- handle_IRQ_event(irq, ®s, action);
+ handle_IRQ_event(irq, regs, action);
spin_lock(&desc->lock);
if (likely(!(desc->status & IRQ_PENDING)))
@@ -407,7 +408,7 @@
irq_exit();
- return 1;
+ return regs;
}
/**
diff -Nru a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
--- a/arch/i386/kernel/process.c Sun Dec 15 20:59:59 2002
+++ b/arch/i386/kernel/process.c Sun Dec 15 20:59:59 2002
@@ -435,6 +435,7 @@
/* never put a printk in __switch_to... printk() calls wake_up*() indirectly */
+ next_p->thread_info->irq_stack = prev_p->thread_info->irq_stack;
unlazy_fpu(prev_p);
/*
diff -Nru a/arch/i386/kernel/smpboot.c b/arch/i386/kernel/smpboot.c
--- a/arch/i386/kernel/smpboot.c Sun Dec 15 20:59:59 2002
+++ b/arch/i386/kernel/smpboot.c Sun Dec 15 20:59:59 2002
@@ -70,6 +70,11 @@
/* Per CPU bogomips and other parameters */
struct cpuinfo_x86 cpu_data[NR_CPUS] __cacheline_aligned;
+/* Per CPU interrupt stacks */
+extern union thread_union init_irq_union;
+union thread_union *irq_stacks[NR_CPUS] __cacheline_aligned =
+ { &init_irq_union, };
+
/* Set when the idlers are all forked */
int smp_threads_ready;
@@ -766,6 +771,28 @@
return (send_status | accept_status);
}
+static void __init setup_irq_stack(struct task_struct *p, int cpu)
+{
+ unsigned long stk;
+
+ stk = __get_free_pages(GFP_KERNEL, THREAD_ORDER);
+ if (!stk)
+ panic("I can't seem to allocate my irq stack. Oh well, giving up.");
+
+ irq_stacks[cpu] = (void *)stk;
+ memset(irq_stacks[cpu], 0, THREAD_SIZE);
+ irq_stacks[cpu]->thread_info.cpu = cpu;
+ irq_stacks[cpu]->thread_info.preempt_count = 1;
+ /* interrupts are not preemptable */
+ p->thread_info->irq_stack = irq_stacks[cpu];
+
+ /* If we want to make the irq stack more than one unit
+ * deep, we can chain then off of the irq_stack pointer
+ * here.
+ */
+}
+
+
extern unsigned long cpu_initialized;
static void __init do_boot_cpu (int apicid)
@@ -789,6 +816,8 @@
if (IS_ERR(idle))
panic("failed fork for CPU %d", cpu);
+ setup_irq_stack(idle, cpu);
+
/*
* We remove it from the pidhash and the runqueue
* once we got the process:
@@ -806,7 +835,13 @@
/* So we see what's up */
printk("Booting processor %d/%d eip %lx\n", cpu, apicid, start_eip);
- stack_start.esp = (void *) (1024 + PAGE_SIZE + (char *)idle->thread_info);
+
+ /* The -4 is to correct for the fact that the stack pointer
+ * is used to find the location of the thread_info structure
+ * by masking off several of the LSBs. Without the -4, esp
+ * is pointing to the page after the one the stack is on.
+ */
+ stack_start.esp = (void *)(THREAD_SIZE - 4 + (char *)idle->thread_info);
/*
* This grunge runs the startup process for
diff -Nru a/include/asm-i386/thread_info.h b/include/asm-i386/thread_info.h
--- a/include/asm-i386/thread_info.h Sun Dec 15 20:59:59 2002
+++ b/include/asm-i386/thread_info.h Sun Dec 15 20:59:59 2002
@@ -30,9 +30,11 @@
__s32 preempt_count; /* 0 => preemptable, <0 => BUG */
mm_segment_t addr_limit; /* thread address space:
+ 0 for interrupts: illegal
0-0xBFFFFFFF for user-thead
0-0xFFFFFFFF for kernel-thread
*/
+ struct thread_info *irq_stack; /* pointer to cpu irq stack */
struct restart_block restart_block;
__u8 supervisor_stack[0];
@@ -47,7 +49,8 @@
#define TI_CPU 0x0000000C
#define TI_PRE_COUNT 0x00000010
#define TI_ADDR_LIMIT 0x00000014
-#define TI_RESTART_BLOCK 0x0000018
+#define TI_IRQ_STACK 0x00000018
+#define TI_RESTART_BLOCK 0x0000022
#endif
@@ -74,6 +77,7 @@
.restart_block = { \
.fn = do_no_restart_syscall, \
}, \
+ .irq_stack = &init_irq_union \
}
#define init_thread_info (init_thread_union.thread_info)
^ permalink raw reply
* [PATCH] (1/4) stack updates for x86
From: Dave Hansen @ 2002-12-16 5:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
These patches originated from Ben LaHaise around 2.5.20. Alan has had
them since 2.5.44-ac2, with apparently no ill effects.
A-thread_info_cleanup-2.5.52+bk-6.patch
Gets asm-i386/thread_info.h ready for the irqstack and
overflow detection patches
--
Dave Hansen
haveblue@us.ibm.com
[-- Attachment #2: A-thread_info_cleanup-2.5.52+bk-6.patch --]
[-- Type: text/plain, Size: 4563 bytes --]
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.858.1.122 -> 1.860
# arch/i386/kernel/head.S 1.17.1.1 -> 1.19
# include/asm-i386/thread_info.h 1.7.1.1 -> 1.9
# include/asm-i386/page.h 1.19 -> 1.20
# arch/i386/kernel/entry.S 1.37.1.4 -> 1.43
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/12/15 haveblue@elm3b96.(none) 1.860
# Merge elm3b96.(none):/work/dave/bk/linux-2.5
# into elm3b96.(none):/work/dave/bk/linux-2.5-thread_info_infra
# --------------------------------------------
#
diff -Nru a/arch/i386/kernel/entry.S b/arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S Sun Dec 15 20:54:32 2002
+++ b/arch/i386/kernel/entry.S Sun Dec 15 20:54:32 2002
@@ -151,7 +151,7 @@
pushl %eax
popfl
- andl $-8192, %ebx # GET_THREAD_INFO
+ GET_THREAD_INFO_WITH_ESP(%ebx) # GET_THREAD_INFO
movl TI_EXEC_DOMAIN(%ebx), %edx # Get the execution domain
call *4(%edx) # Call the lcall7 handler for the domain
addl $4, %esp
diff -Nru a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
--- a/arch/i386/kernel/head.S Sun Dec 15 20:54:32 2002
+++ b/arch/i386/kernel/head.S Sun Dec 15 20:54:32 2002
@@ -15,6 +15,7 @@
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/desc.h>
+#include <asm/thread_info.h>
#define OLD_CL_MAGIC_ADDR 0x90020
#define OLD_CL_MAGIC 0xA33F
@@ -305,7 +306,7 @@
ret
ENTRY(stack_start)
- .long init_thread_union+8192
+ .long init_thread_union+THREAD_SIZE
.long __KERNEL_DS
/* This is the default interrupt "handler" :-) */
diff -Nru a/include/asm-i386/page.h b/include/asm-i386/page.h
--- a/include/asm-i386/page.h Sun Dec 15 20:54:32 2002
+++ b/include/asm-i386/page.h Sun Dec 15 20:54:32 2002
@@ -3,7 +3,11 @@
/* PAGE_SHIFT determines the page size */
#define PAGE_SHIFT 12
-#define PAGE_SIZE (1UL << PAGE_SHIFT)
+#ifndef __ASSEMBLY__
+#define PAGE_SIZE (1UL << PAGE_SHIFT)
+#else
+#define PAGE_SIZE (1 << PAGE_SHIFT)
+#endif
#define PAGE_MASK (~(PAGE_SIZE-1))
#define LARGE_PAGE_MASK (~(LARGE_PAGE_SIZE-1))
diff -Nru a/include/asm-i386/thread_info.h b/include/asm-i386/thread_info.h
--- a/include/asm-i386/thread_info.h Sun Dec 15 20:54:32 2002
+++ b/include/asm-i386/thread_info.h Sun Dec 15 20:54:32 2002
@@ -9,6 +9,7 @@
#ifdef __KERNEL__
+#include <asm/page.h>
#ifndef __ASSEMBLY__
#include <asm/processor.h>
#endif
@@ -57,11 +58,14 @@
*
* preempt_count needs to be 1 initially, until the scheduler is functional.
*/
+#define THREAD_ORDER 1
+#define INIT_THREAD_SIZE THREAD_SIZE
+
#ifndef __ASSEMBLY__
#define INIT_THREAD_INFO(tsk) \
{ \
- .task = &tsk, \
+ .task = &tsk, \
.exec_domain = &default_exec_domain, \
.flags = 0, \
.cpu = 0, \
@@ -75,30 +79,36 @@
#define init_thread_info (init_thread_union.thread_info)
#define init_stack (init_thread_union.stack)
+/* thread information allocation */
+#define THREAD_SIZE (PAGE_SIZE << THREAD_ORDER)
+#define alloc_thread_info() ((struct thread_info *) __get_free_pages(GFP_KERNEL,THREAD_ORDER))
+#define free_thread_info(ti) free_pages((unsigned long) (ti), THREAD_ORDER)
+#define get_thread_info(ti) get_task_struct((ti)->task)
+#define put_thread_info(ti) put_task_struct((ti)->task)
+
/* how to get the thread information struct from C */
static inline struct thread_info *current_thread_info(void)
{
struct thread_info *ti;
- __asm__("andl %%esp,%0; ":"=r" (ti) : "0" (~8191UL));
+ __asm__("andl %%esp,%0; ":"=r" (ti) : "0" (~(THREAD_SIZE - 1)));
return ti;
}
-/* thread information allocation */
-#define THREAD_SIZE (2*PAGE_SIZE)
-#define alloc_thread_info() ((struct thread_info *) __get_free_pages(GFP_KERNEL,1))
-#define free_thread_info(ti) free_pages((unsigned long) (ti), 1)
-#define get_thread_info(ti) get_task_struct((ti)->task)
-#define put_thread_info(ti) put_task_struct((ti)->task)
-
#else /* !__ASSEMBLY__ */
+#define THREAD_SIZE (PAGE_SIZE << THREAD_ORDER)
+
/* how to get the thread information struct from ASM */
#define GET_THREAD_INFO(reg) \
- movl $-8192, reg; \
+ movl $-THREAD_SIZE, reg; \
andl %esp, reg
-#endif
+/* use this one if reg already contains %esp */
+#define GET_THREAD_INFO_WITH_ESP(reg) \
+ andl $-THREAD_SIZE, reg
+#endif
+
/*
* thread information flags
* - these are process state flags that various assembly files may need to access
^ permalink raw reply
* [PATCH] (4/4) stack updates for x86
From: Dave Hansen @ 2002-12-16 5:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 261 bytes --]
D-4k-stack-2.5.52+bk-6.patch
make a config option to turn on 4k stacks.
Make sure this is applied too, or you'll oops when bringing up
secondary cpus:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103956921711074&w=2
--
Dave Hansen
haveblue@us.ibm.com
[-- Attachment #2: D-4k-stack-2.5.52-6.patch --]
[-- Type: text/plain, Size: 2122 bytes --]
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.862.1.4 -> 1.867
# include/asm-i386/thread_info.h 1.13.1.1 -> 1.17
# arch/i386/Kconfig 1.15 -> 1.16
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/12/15 haveblue@elm3b96.(none) 1.867
# Merge elm3b96.(none):/work/dave/bk/linux-2.5-irq-stack+overflow-detect
# into elm3b96.(none):/work/dave/bk/linux-2.5-4k_stack
# --------------------------------------------
#
diff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig Sun Dec 15 21:27:56 2002
+++ b/arch/i386/Kconfig Sun Dec 15 21:27:56 2002
@@ -622,6 +622,16 @@
low memory. Setting this option will put user-space page table
entries in high memory.
+config 4K_STACK
+ bool "Use smaller 4k per-task stacks"
+ help
+ This option will shrink the kernel's per-task stack from 8k to
+ 4k. This will greatly increase your chance of overflowing it.
+ But, if you use the per-cpu interrupt stacks as well, your chances
+ go way down. Also try the CONFIG_X86_STACK_CHECK overflow
+ detection. It is much more reliable than the currently in-kernel
+ version.
+
config MATH_EMULATION
bool "Math emulation"
---help---
diff -Nru a/include/asm-i386/thread_info.h b/include/asm-i386/thread_info.h
--- a/include/asm-i386/thread_info.h Sun Dec 15 21:27:56 2002
+++ b/include/asm-i386/thread_info.h Sun Dec 15 21:27:56 2002
@@ -61,10 +61,16 @@
*
* preempt_count needs to be 1 initially, until the scheduler is functional.
*/
-#define THREAD_ORDER 1
+#ifdef CONFIG_4K_STACK
+#define THREAD_ORDER 0
+#define STACK_WARN 0x200
+#define STACK_PANIC 0x100
+#else
+#define THREAD_ORDER 1
+#define STACK_WARN ((THREAD_SIZE)>>1)
+#define STACK_PANIC 0x100
+#endif
#define INIT_THREAD_SIZE THREAD_SIZE
-#define STACK_PANIC 0x200ul
-#define STACK_WARN ((THREAD_SIZE)>>1)
#ifndef __ASSEMBLY__
^ permalink raw reply
* Re: Intel ICH4 ide not working for 2.4.19 and 2.4.20
From: Alan Cox @ 2002-12-16 6:37 UTC (permalink / raw)
To: Bill Metzenthen; +Cc: Linux Kernel Mailing List
In-Reply-To: <200212141848.41037.billm@melbpc.org.au>
On Sat, 2002-12-14 at 07:48, Bill Metzenthen wrote:
> I've looked through the archives and there doesn't appear to be anyone else
> with this particular problem. Does anyone have an idea about what I should
> do to fix my problem?
I'm pretty sure I know what this is, if so it'll be fixed fairly soon
^ permalink raw reply
* Re: [parisc-linux] problems with PCI IDE controller
From: Alan Cox @ 2002-12-16 6:28 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Joerg Steindlberger, PARISC-LINUX
In-Reply-To: <20021214131048.L10991@parcelfarce.linux.theplanet.co.uk>
On Sat, 2002-12-14 at 13:10, Matthew Wilcox wrote:
> > hp-c240 login: Uniform Multi-Platform E-IDE driver Revision: 6.31
> > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> > PDC20268: IDE controller on PCI bus 00 dev 08
> > PDC20268: chipset revision 2
> > PDC20268: not 100% native mode: will probe irqs later
Is this a plug in card. For some reason it has been left in non native
mode so won't work as a plug in board.
^ permalink raw reply
* Re: Linux 2.4.21-pre1
From: Alan Cox @ 2002-12-16 6:34 UTC (permalink / raw)
To: Ralf Hildebrandt; +Cc: lkml
In-Reply-To: <20021215095630.GD16227@charite.de>
On Sun, 2002-12-15 at 09:56, Ralf Hildebrandt wrote:
> * Alan Cox <alan@lxorguk.ukuu.org.uk>:
>
> > The hardware isnt at the normal ide base addresse, yet the chip is
> > reporting that it isnt in native mode. As far as I can see this
> > configuration isnt allowed.
> >
> > We see that the chip isnt in native mode so we defer to the legacy
> > scanner. Since the ports are not valid the legacy scanner doesn't find
> > them.
>
> Will the fix be for thatbe in 2.4.20-ac3 / 2.4.21-pre2?
Soon I hope
^ permalink raw reply
* Re: increase base memory
From: Sergey Suleymanov @ 2002-12-16 5:31 UTC (permalink / raw)
To: Linux-MSDOS Mailing list
In-Reply-To: <3DFD302F.1060806@yahoo.com>
>>>>> Stas Sergeev writes:
Stas> Increasing the base memory above 640Kb is definitely the bad
Stas> idea, as it is used very rarely even in a pure DOS and will
Stas> cost you the inability to display graphics.
By the way, 0.99.13 (pre-1.0) works well with 704k base. ;)
--
Sergey Suleymanov
^ permalink raw reply
* Re: [PROBLEM]: "make rpm" fails on RH 8.0
From: Alan Cox @ 2002-12-16 6:06 UTC (permalink / raw)
To: Tarkan Erimer; +Cc: Linux Kernel Mailing List
In-Reply-To: <200212151417.34213.tarkane@solmaz.com.tr>
On Sun, 2002-12-15 at 12:17, Tarkan Erimer wrote:
>
> Hi,
>
> I try to make kernel rpms via "make rpm" command but, it fails to build.
> Because, In RH 8.0, build options of rpm moved to "rpmbuild" command, instead
> of "rpm" command. I think,some modifications to kernel build process will be
> required to fix it.
Good point. I'll sort that out
^ permalink raw reply
* Re: 2.4.20 st + aic7xxx (Adaptec 19160B) + VIA KT333 repeatable freeze
From: Kevin Easton @ 2002-12-16 5:21 UTC (permalink / raw)
To: Keith Owens; +Cc: linux-kernel
In-Reply-To: <8477.1040014052@kao2.melbourne.sgi.com>
On Mon, Dec 16, 2002 at 03:47:32PM +1100, Keith Owens wrote:
> On Mon, 16 Dec 2002 14:52:26 +1100,
> caf@guarana.org wrote:
> >Running with nmi_watchdog=2 has made the problem a bit harder to
> >reproduce[1], but when it does hang it doesn't produce a trace (I left it
> >for several minutes just in case..). Checking /proc/interrupts after
> >boot shows around 16 NMIs, which I presume means that it's being used? -
> >although it didn't seem to be going up at anything like once every 5
> >seconds.
>
> nmi_watchdog=2 should pop once per second, nmi_watchdog=1 pops HZ
> (usually 100) times per second. Anything less than once a second is
> not working. One possibility is CONFIG_X86_UP_APIC, it should be y for
> UP to use nmi_watchdog.
Interesting - I do have CONFIG_X86_UP_APIC set, and the nmi_watchdog is
doing _something_, because without it on the kernel commandline I get 0
NMIs.
> >Is it possible that I'm not seeing the trace because I'm using a VGA
> >virtual console rather than a real serial console?
>
> Depends on your boot parameters for console and the levels of console
> printk. Console output to X is unlikely to work, output to VGA
> (including virtual consoles) should work. Except that some
> distributions change printk levels and even redirect output to a
> different virtual console.
>
> cat /proc/cmdline should have no console setting or 'console=tty0'.
> Change boot options and reboot if necessary.
>
> cat /proc/sys/kernel/printk should report 6 4 1 7, if not then
> echo "6 4 1 7" > /proc/sys/kernel/printk
Ahh, that could be a problem, my system's default is "7 4 1 7".
- Kevin.
^ permalink raw reply
* Re: Alcatel speedtouch USB driver and SMP.
From: Greg KH @ 2002-12-16 5:13 UTC (permalink / raw)
To: Colin Paul Adams; +Cc: linux-kernel
In-Reply-To: <m3hedfhd5l.fsf@colina.demon.co.uk>
On Sun, Dec 15, 2002 at 08:58:14AM +0000, Colin Paul Adams wrote:
> >>>>> "Greg" == Greg KH <greg@kroah.com> writes:
>
> Greg> On Sun, Dec 15, 2002 at 07:10:33AM +0000, Colin Paul Adams
> Greg> wrote:
> >> Can anyone tell me if the speedtouch driver is SMP safe yet?
>
> Greg> Which driver? I know of at least 3 different ones :(
>
> drivers/usb/misc/speedtouch.c
Ah good, you're using one that the source is available for :)
I think the developer has said it will work on SMP machines, but what
problems are you having, and have you asked the author of the code?
> Where are the others?
I don't know, but I know they are out there...
thanks,
greg k-h
^ permalink raw reply
* [PATCH] 2.5.52 fix intermezzo build (trivial)
From: Randy.Dunlap @ 2002-12-16 4:05 UTC (permalink / raw)
To: torvalds, braam, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 74 bytes --]
Hi,
This allows intermezzo to build in 2.5.52.
Is this OK, Peter?
~Randy
[-- Attachment #2: intermez-build-2552.patch --]
[-- Type: text/plain, Size: 591 bytes --]
--- ./fs/intermezzo/Makefile%IMZ Sun Dec 15 18:08:13 2002
+++ ./fs/intermezzo/Makefile Sun Dec 15 20:01:06 2002
@@ -5,7 +5,7 @@
obj-$(CONFIG_INTERMEZZO_FS) += intermezzo.o
intermezzo-objs := cache.o dcache.o dir.o ext_attr.o file.o fileset.o \
- inode.o io_daemon.o journal.o journal_ext2.o journal_ext3.o \
+ inode.o journal.o journal_ext2.o journal_ext3.o \
journal_obdfs.o journal_reiserfs.o journal_tmpfs.o journal_xfs.o \
kml_reint.o kml_unpack.o methods.o presto.o psdev.o replicator.o \
super.o sysctl.o upcall.o vfs.o
^ permalink raw reply
* sendmail
From: Veggies Unite! @ 2002-12-16 4:59 UTC (permalink / raw)
To: linux-newbie
I hope that this is the correct place to e-mail this question - if
not, I would appreciate being re-directed. I've set up SuSe 8.0 on a
computer running through a router and a cable modem. I have a
static IP, and I have a domain name pointing to the IP via a
Registrar that also handles a POP3 account. I've set up Majordomo on
my computer and would like to configure sendmail as a mail server so
that it will handle mailing lists aliases for Majordomo. Also, I
would need to run a POP server to allow me to receive mail from my
server instead of the Registar.
In order for the aliases for majordomo to work, do I have cancel my
mail coming from the POP3 account via the Registrar?
Please let me know of any documentation on this or if you have
specific advice on what I would need to do.
Thanks,
Yvette
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: 2.4.20 st + aic7xxx (Adaptec 19160B) + VIA KT333 repeatable freeze
From: Kevin Easton @ 2002-12-16 5:04 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: Keith Owens, Kevin Easton, linux-kernel
In-Reply-To: <17460000.1039982505@aslan.btc.adaptec.com>
On Sun, Dec 15, 2002 at 01:01:45PM -0700, Justin T. Gibbs wrote:
> > On Fri, 13 Dec 2002 11:51:27 +1100,
> > Kevin Easton <kevin@sylandro.com> wrote:
> >> I'm not sure exactly where this problem fits in, but I'm getting a
> >> completely repeatable freeze (100% lockup, no response to keyboard)
> >> triggered by writing to /dev/st0 (dd if=/dev/urandom of=/dev/st0 bs=512
> >> count=163840 will reproduce it).
> >> So... does anyone have any ideas how I should start trying to track this
> >> down?
>
> You might also look into your BIOS to ensure that the option "PCI Byte
> Merging" is disabled. This option allows the chipset to perform illegal
> byte merging on the PCI bus that will upset the Adaptec. Since the byte
> merging will only occur in certain scenarios (heavily dependent on what
> is going on with the SCSI bus), you may only see the lockup when accessing
> a particular device or running a certain program.
>
> The latest versions of the aic7xxx and aic79xx drivers will automatically
> detect this broken VIA behavior and will fall back to using PIO for register
> access. Although I haven't generated patches against 2.4.20, you can pull
> down a src tarball for 2.4.X that should just drop in:
Well, like I thought, this BIOS (it's an ASUS A7V333 mobo) doesn't have
an option for PCI Byte Merging - it has very few PCI options at all.
I'm going to update the BIOS to see if that gains me anything useful.
I took a clean 2.4.20 source tree and overlaid it with the contents of
aic79xx-linux-2.4.20-20021213.tar.gz, and it doesn't seem to have fixed
the problem completely, though it is *much* harder to trigger it now - I
thought it was working, but the same problem reappeared after copying
just over 4.5Gb to a tape.
As I mentioned in my reply to Keith, the NMI watchdog isn't even
triggering after this crash, which seems a little odd to me.
- Kevin.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.