Re: 2.6.13-mm1 X86_64: All 32bit programs segfault
Andi Kleen wrote: If you catch a crash in gdb and type x/i $pc what do you see? -Andi Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1431820864 (LWP 2839)] 0x00c40471 in __pthread_initialize_minimal_internal () from /lib/libpthread.so.0 (gdb) x/i $pc 0xc40471 <__pthread_initialize_minimal_internal+78>:mov 0x2e8(%eax),%edx (gdb) info registers eax0x0 0 ^^ ecx0x5557da88 1431820936 edx0x1 1 ebx0xd4a8 -11096 esp0xd1e4 0xd1e4 ebp0xd4a8 0xd4a8 esi0x5557da40 1431820864 edi0x0 0 eip0xc40471 0xc40471 eflags 0x10202 66050 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x63 99 - 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.6.13-mm1 X86_64: All 32bit programs segfault
Andrew Morton wrote: it works fine. I can't reproduce this with the current -mm lineup. I compiled up a 32-bit app on x86 and transferred that across. Maybe it got fixed. Please test 2.6.13-mm2, which appears to be an hour or two away. If it still fails then I'd need a recipe (including URLs and stuff) with which to reproduce it please. You need a program which uses threads - NPTL ones I suspect. Normal programs work fine even on my setup. Any way I will give -mm2 a try and see. Parag - 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.6.13-mm1 X86_64: All 32bit programs segfault
On Thursday 08 September 2005 10:44, Andrew Morton wrote: > Parag Warudkar <[EMAIL PROTECTED]> wrote: > > Andi Kleen wrote: > > >Hmm - not many x86-64 patches in mm1. 2.6.13 definitely works. > > > > 2.6.13-git7 works. So something in -mm has gone bad (if not x86_64, may > > be i386 or arch-independent changes?) > > It seems it has got something to do with the sys_set_tid_address as > > evident from the strace output below. > > Another thing - If I set LD_ASSUME_KERNEL=2.4 and then run the binary, > > it works fine. > > I can't reproduce this with the current -mm lineup. I compiled up a 32-bit > app on x86 and transferred that across. Did you use a threaded program? It appears to be related to that. (BTW you can compile 32bit on 64bit too by passing -m32) -Andi - 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.6.13-mm1 X86_64: All 32bit programs segfault
Parag Warudkar <[EMAIL PROTECTED]> wrote: > > Andi Kleen wrote: > > >Hmm - not many x86-64 patches in mm1. 2.6.13 definitely works. > > > > > 2.6.13-git7 works. So something in -mm has gone bad (if not x86_64, may > be i386 or arch-independent changes?) > It seems it has got something to do with the sys_set_tid_address as > evident from the strace output below. > Another thing - If I set LD_ASSUME_KERNEL=2.4 and then run the binary, > it works fine. I can't reproduce this with the current -mm lineup. I compiled up a 32-bit app on x86 and transferred that across. Maybe it got fixed. Please test 2.6.13-mm2, which appears to be an hour or two away. If it still fails then I'd need a recipe (including URLs and stuff) with which to reproduce it please. - 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.6.13-mm1 X86_64: All 32bit programs segfault
Parag Warudkar [EMAIL PROTECTED] wrote: Andi Kleen wrote: Hmm - not many x86-64 patches in mm1. 2.6.13 definitely works. 2.6.13-git7 works. So something in -mm has gone bad (if not x86_64, may be i386 or arch-independent changes?) It seems it has got something to do with the sys_set_tid_address as evident from the strace output below. Another thing - If I set LD_ASSUME_KERNEL=2.4 and then run the binary, it works fine. I can't reproduce this with the current -mm lineup. I compiled up a 32-bit app on x86 and transferred that across. Maybe it got fixed. Please test 2.6.13-mm2, which appears to be an hour or two away. If it still fails then I'd need a recipe (including URLs and stuff) with which to reproduce it please. - 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.6.13-mm1 X86_64: All 32bit programs segfault
On Thursday 08 September 2005 10:44, Andrew Morton wrote: Parag Warudkar [EMAIL PROTECTED] wrote: Andi Kleen wrote: Hmm - not many x86-64 patches in mm1. 2.6.13 definitely works. 2.6.13-git7 works. So something in -mm has gone bad (if not x86_64, may be i386 or arch-independent changes?) It seems it has got something to do with the sys_set_tid_address as evident from the strace output below. Another thing - If I set LD_ASSUME_KERNEL=2.4 and then run the binary, it works fine. I can't reproduce this with the current -mm lineup. I compiled up a 32-bit app on x86 and transferred that across. Did you use a threaded program? It appears to be related to that. (BTW you can compile 32bit on 64bit too by passing -m32) -Andi - 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.6.13-mm1 X86_64: All 32bit programs segfault
Andrew Morton wrote: it works fine. I can't reproduce this with the current -mm lineup. I compiled up a 32-bit app on x86 and transferred that across. Maybe it got fixed. Please test 2.6.13-mm2, which appears to be an hour or two away. If it still fails then I'd need a recipe (including URLs and stuff) with which to reproduce it please. You need a program which uses threads - NPTL ones I suspect. Normal programs work fine even on my setup. Any way I will give -mm2 a try and see. Parag - 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.6.13-mm1 X86_64: All 32bit programs segfault
Andi Kleen wrote: If you catch a crash in gdb and type x/i $pc what do you see? -Andi Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1431820864 (LWP 2839)] 0x00c40471 in __pthread_initialize_minimal_internal () from /lib/libpthread.so.0 (gdb) x/i $pc 0xc40471 __pthread_initialize_minimal_internal+78:mov 0x2e8(%eax),%edx (gdb) info registers eax0x0 0 ^^ ecx0x5557da88 1431820936 edx0x1 1 ebx0xd4a8 -11096 esp0xd1e4 0xd1e4 ebp0xd4a8 0xd4a8 esi0x5557da40 1431820864 edi0x0 0 eip0xc40471 0xc40471 eflags 0x10202 66050 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x63 99 - 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.6.13-mm1 X86_64: All 32bit programs segfault
On Thursday 08 September 2005 07:10, Parag Warudkar wrote: > Andi Kleen wrote: > >Hmm - not many x86-64 patches in mm1. 2.6.13 definitely works. > > 2.6.13-git7 works. So something in -mm has gone bad (if not x86_64, may > be i386 or arch-independent changes?) > It seems it has got something to do with the sys_set_tid_address as > evident from the strace output below. If you catch a crash in gdb and type x/i $pc what do you see? -Andi - 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.6.13-mm1 X86_64: All 32bit programs segfault
Andi Kleen wrote:
Hmm - not many x86-64 patches in mm1. 2.6.13 definitely works.
2.6.13-git7 works. So something in -mm has gone bad (if not x86_64, may
be i386 or arch-independent changes?)
It seems it has got something to do with the sys_set_tid_address as
evident from the strace output below.
Another thing - If I set LD_ASSUME_KERNEL=2.4 and then run the binary,
it works fine.
Last lines of strace -f + the kernel message from dmesg might be useful.
dmesg
Sep 7 00:14:23 localhost kernel: mozilla-xremote[4492]: segfault at
02e8 rip 00c40471 rsp d334 error 4
Sep 7 00:14:24 localhost kernel: thunderbird-bin[4500]: segfault at
02e8 rip 00c40471 rsp cfe4 error 4
Sep 7 00:15:02 localhost kernel: mozilla-xremote[4518]: segfault at
02e8 rip 00c40471 rsp ce84 error 4 Sep
7 00:15:02 localhost kernel: thunderbird-bin[4526]: segfault at
02e8 rip 00c40471 rsp bbe4 error 4
strace -f ./thunderbird
---
[pid 2888] fstat64(0x3, 0xb25c)= 0
[pid 2888] old_mmap(0x12c8c00c7d000, 8804682956805,
PROT_READ|PROT_WRITE, 0xc /* MAP_???
*/|MAP_FIXED|MAP_ANONYMOUS|MAP_POPULATE|MAP_NONBLOCK|MAP_GROWSDOWN|MAP_EXECUTABLE|MAP_LOCKED|0xfffe,
1, 0xb071e0b14c) = 0xc7d000
[pid 2888] old_mmap(0x10c8f000, 8873402433539,
PROT_READ|PROT_WRITE, 0xc /* MAP_???
*/|MAP_FIXED|MAP_ANONYMOUS|MAP_POPULATE|MAP_NONBLOCK|MAP_GROWSDOWN|MAP_EXECUTABLE|MAP_LOCKED|0xfffe,
1, 0xb071e0b14c) = 0xc8f000
[pid 2888] close(3)= 0
[pid 2888] old_mmap(0x1000, 14602067,
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf8,
0x4 /* MAP_???
*/|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE|MAP_POPULATE|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|0xb00680,
48, 0x800b071e0) = 0x5599e000
[pid 2888] old_mmap(0x1000, 14602067,
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf8,
0x4 /* MAP_???
*/|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE|MAP_POPULATE|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|0xb00680,
19, 0x800b071e0) = 0x5599f000
[pid 2888] old_mmap(0x1000, 14602067,
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf8,
0x4 /* MAP_???
*/|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE|MAP_POPULATE|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|0xb00680,
2832, 0x2000b033df) = 0x559a
[pid 2888] set_thread_area(0xce20) = 0
[pid 2888] mprotect(0xc34000, 8192, PROT_READ) = 0
[pid 2888] mprotect(0xc73000, 4096, PROT_READ) = 0
[pid 2888] mprotect(0xc4a000, 4096, PROT_READ) = 0
[pid 2888] mprotect(0xc79000, 4096, PROT_READ) = 0
[pid 2888] mprotect(0xb0d000, 4096, PROT_READ) = 0
[pid 2888] munmap(0x555d8000, 155672) = 0
[pid 2888] set_tid_address(0x559a0608) = 2888
^^^
[pid 2888] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 2883 resumed
Process 2888 detached
[pid 2883] <... chroot resumed> ) = 2888
[ Process PID=2883 runs in 64 bit mode. ]
[pid 2883] fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1),
...}) = 0
[pid 2883] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2da2d000
[pid 2883] open("/usr/share/locale/locale.alias", O_RDONLY) = 3
[pid 2883] fstat(3, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0
[pid 2883] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2da2e000
[pid 2883] read(3, "# Locale name alias data base.\n#"..., 4096) = 2528
[pid 2883] read(3, "", 4096) = 0
[pid 2883] close(3)= 0
[pid 2883] munmap(0x2da2e000, 4096) = 0
[pid 2883] open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 2883] open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 2883] open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 2883] open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 2883] open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 2883] open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
[pid 2883] write(2, "./run-mozilla.sh: line 159: 288"...,
76./run-mozilla.sh: line 159: 2888 Segmentation fault "$prog"
${1+"$@"}
) = 76
[pid 2883] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 2883] --- SIGCHLD (Child exited) @ 0 (0) ---
[pid 2883] wait4(-1, 0x7fe133d4, WNOHANG, NULL) = -1 ECHILD (No
child processes)
[pid 2883] rt_sigreturn(0x) = 0
[pid 2883] rt_sigaction(SIGINT, {SIG_DFL}, {0x4312b5, [], SA_RESTORER,
0x3116d2f330}, 8) = 0
[pid 2883] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid
Re: 2.6.13-mm1 X86_64: All 32bit programs segfault
On Thursday 08 September 2005 05:54, Parag Warudkar wrote: > I am clueless as to what's going on but just raising a flag in case it > is a not yet known problem. > Thunderbird, 32bit Sun Java and Opera are the ones I tried. They all > work fine with the Fedora 2.6.12-x kernel but > consistently seg fault with 2.6.13-mm1. Hmm - not many x86-64 patches in mm1. 2.6.13 definitely works. > > Parag > > Sample stack trace for java - > gdb ./java Last lines of strace -f + the kernel message from dmesg might be useful. -Andi - 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.6.13-mm1 X86_64: All 32bit programs segfault
On Thursday 08 September 2005 05:54, Parag Warudkar wrote: I am clueless as to what's going on but just raising a flag in case it is a not yet known problem. Thunderbird, 32bit Sun Java and Opera are the ones I tried. They all work fine with the Fedora 2.6.12-x kernel but consistently seg fault with 2.6.13-mm1. Hmm - not many x86-64 patches in mm1. 2.6.13 definitely works. Parag Sample stack trace for java - gdb ./java Last lines of strace -f + the kernel message from dmesg might be useful. -Andi - 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.6.13-mm1 X86_64: All 32bit programs segfault
Andi Kleen wrote:
Hmm - not many x86-64 patches in mm1. 2.6.13 definitely works.
2.6.13-git7 works. So something in -mm has gone bad (if not x86_64, may
be i386 or arch-independent changes?)
It seems it has got something to do with the sys_set_tid_address as
evident from the strace output below.
Another thing - If I set LD_ASSUME_KERNEL=2.4 and then run the binary,
it works fine.
Last lines of strace -f + the kernel message from dmesg might be useful.
dmesg
Sep 7 00:14:23 localhost kernel: mozilla-xremote[4492]: segfault at
02e8 rip 00c40471 rsp d334 error 4
Sep 7 00:14:24 localhost kernel: thunderbird-bin[4500]: segfault at
02e8 rip 00c40471 rsp cfe4 error 4
Sep 7 00:15:02 localhost kernel: mozilla-xremote[4518]: segfault at
02e8 rip 00c40471 rsp ce84 error 4 Sep
7 00:15:02 localhost kernel: thunderbird-bin[4526]: segfault at
02e8 rip 00c40471 rsp bbe4 error 4
strace -f ./thunderbird
---
[pid 2888] fstat64(0x3, 0xb25c)= 0
[pid 2888] old_mmap(0x12c8c00c7d000, 8804682956805,
PROT_READ|PROT_WRITE, 0xc /* MAP_???
*/|MAP_FIXED|MAP_ANONYMOUS|MAP_POPULATE|MAP_NONBLOCK|MAP_GROWSDOWN|MAP_EXECUTABLE|MAP_LOCKED|0xfffe,
1, 0xb071e0b14c) = 0xc7d000
[pid 2888] old_mmap(0x10c8f000, 8873402433539,
PROT_READ|PROT_WRITE, 0xc /* MAP_???
*/|MAP_FIXED|MAP_ANONYMOUS|MAP_POPULATE|MAP_NONBLOCK|MAP_GROWSDOWN|MAP_EXECUTABLE|MAP_LOCKED|0xfffe,
1, 0xb071e0b14c) = 0xc8f000
[pid 2888] close(3)= 0
[pid 2888] old_mmap(0x1000, 14602067,
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf8,
0x4 /* MAP_???
*/|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE|MAP_POPULATE|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|0xb00680,
48, 0x800b071e0) = 0x5599e000
[pid 2888] old_mmap(0x1000, 14602067,
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf8,
0x4 /* MAP_???
*/|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE|MAP_POPULATE|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|0xb00680,
19, 0x800b071e0) = 0x5599f000
[pid 2888] old_mmap(0x1000, 14602067,
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf8,
0x4 /* MAP_???
*/|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE|MAP_POPULATE|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|0xb00680,
2832, 0x2000b033df) = 0x559a
[pid 2888] set_thread_area(0xce20) = 0
[pid 2888] mprotect(0xc34000, 8192, PROT_READ) = 0
[pid 2888] mprotect(0xc73000, 4096, PROT_READ) = 0
[pid 2888] mprotect(0xc4a000, 4096, PROT_READ) = 0
[pid 2888] mprotect(0xc79000, 4096, PROT_READ) = 0
[pid 2888] mprotect(0xb0d000, 4096, PROT_READ) = 0
[pid 2888] munmap(0x555d8000, 155672) = 0
[pid 2888] set_tid_address(0x559a0608) = 2888
^^^
[pid 2888] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 2883 resumed
Process 2888 detached
[pid 2883] ... chroot resumed ) = 2888
[ Process PID=2883 runs in 64 bit mode. ]
[pid 2883] fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1),
...}) = 0
[pid 2883] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2da2d000
[pid 2883] open(/usr/share/locale/locale.alias, O_RDONLY) = 3
[pid 2883] fstat(3, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0
[pid 2883] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2da2e000
[pid 2883] read(3, # Locale name alias data base.\n#..., 4096) = 2528
[pid 2883] read(3, , 4096) = 0
[pid 2883] close(3)= 0
[pid 2883] munmap(0x2da2e000, 4096) = 0
[pid 2883] open(/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo,
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 2883] open(/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo,
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 2883] open(/usr/share/locale/en_US/LC_MESSAGES/libc.mo,
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 2883] open(/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo,
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 2883] open(/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo,
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 2883] open(/usr/share/locale/en/LC_MESSAGES/libc.mo, O_RDONLY) =
-1 ENOENT (No such file or directory)
[pid 2883] write(2, ./run-mozilla.sh: line 159: 288...,
76./run-mozilla.sh: line 159: 2888 Segmentation fault $prog
${1+$@}
) = 76
[pid 2883] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 2883] --- SIGCHLD (Child exited) @ 0 (0) ---
[pid 2883] wait4(-1, 0x7fe133d4, WNOHANG, NULL) = -1 ECHILD (No
child processes)
[pid 2883] rt_sigreturn(0x) = 0
[pid 2883] rt_sigaction(SIGINT, {SIG_DFL}, {0x4312b5, [], SA_RESTORER,
0x3116d2f330}, 8) = 0
[pid 2883] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 2883]
Re: 2.6.13-mm1 X86_64: All 32bit programs segfault
On Thursday 08 September 2005 07:10, Parag Warudkar wrote: Andi Kleen wrote: Hmm - not many x86-64 patches in mm1. 2.6.13 definitely works. 2.6.13-git7 works. So something in -mm has gone bad (if not x86_64, may be i386 or arch-independent changes?) It seems it has got something to do with the sys_set_tid_address as evident from the strace output below. If you catch a crash in gdb and type x/i $pc what do you see? -Andi - 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.6.13-mm1
Jesper wrote: > Something like that would be just fine for the > patches that have been sent on to Linus. No - not just the patches sent to Linus - that's a burden on Andrew to separate things out. Andrew can put the boiler plate statement on _all_ drop messages > If I just sent the patch to Linus, that is > probably why I dropped it here. At the very least, he gets to cuss us out for not being able to read, instead of not being able to associate the 'patch to Linus' message with the 'drop' message a few hours later. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - 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.6.13-mm1
On 9/7/05, Paul Jackson <[EMAIL PROTECTED]> wrote: > Andrew wrote" > > So then I was asked to include an explanation > > with the drop message and that all got too hard so I turned them off. > > > > > > > Dang it, Andrew. It didn't have to be hard. Just adding a > boiler plate sentence to all the drop messages saying something > like: > > If I just sent the patch to Linus, that is > probably why I dropped it here. > > That should be enough of a clue for most folks. I agree completely. Something like that would be just fine for the patches that have been sent on to Linus. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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.6.13-mm1
Paul Jackson <[EMAIL PROTECTED]> wrote: > > Andrew wrote" > > So then I was asked to include an explanation > > with the drop message and that all got too hard so I turned them off. > > > > > > > Dang it, Andrew. It didn't have to be hard. I got three unhappy emails and turned it off again ;) > Just adding a > boiler plate sentence to all the drop messages saying something > like: > > If I just sent the patch to Linus, that is > probably why I dropped it here. > > That should be enough of a clue for most folks. OK.. - 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.6.13-mm1
Andrew wrote" > So then I was asked to include an explanation > with the drop message and that all got too hard so I turned them off. > > Dang it, Andrew. It didn't have to be hard. Just adding a boiler plate sentence to all the drop messages saying something like: If I just sent the patch to Linus, that is probably why I dropped it here. That should be enough of a clue for most folks. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - 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.6.13-mm1
On Fri, Sep 02, 2005 at 01:57:35PM -0700, Andrew Morton wrote: > Cons: > > - Additional arguments to various fastpath functions One possibility is to split the async and sync versions by way of inline functions. That will result in more icache pressure, though, which makes it a questionable optimization. > - Additional code size > > - Additional code complexity These are general concerns of all new features. It is possible to split the code out into separate codepaths (the 2.4 async read/write paths were completely new), but that cuts down on code sharing between the traditional sync read/writes and async code. If that is a requirement for merging, then they certainly could be split out and grown in a separate aio module, but that leads to other maintenence headches. The flip side of this question is that we already have O_DIRECT and all of its associated overhead, yet the vast majority of systems don't use it in the course of day to day operation. Maybe we should have config options for these things, but where does the line get drawn? > - Significantly degrades collective understanding of how the VFS works. That can be improved through the use of debugging options to teach people that aio_* functions should not block, which is the only real difference between async and non-async functions -- if you'd block, return -EIOCBRETRY instead. > Pros: > > - Unclear. We already have a number of users demanding buffered filesystem aio -- the UML patches to use aio just went in. Samba is able to make use of aio. There are lots of high performance server applications which require aio and filesystem caching (think iSCSI servers, web servers/caches). Right now the only way to do that is via threads, which brings into play a lot of other overhead. AIO is one of the last areas in which we don't provide a suitable implementation for use in normal applications, only highly specialised database users. -ben - 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.6.13-mm1
On Fri, Sep 02, 2005 at 01:57:35PM -0700, Andrew Morton wrote: Cons: - Additional arguments to various fastpath functions One possibility is to split the async and sync versions by way of inline functions. That will result in more icache pressure, though, which makes it a questionable optimization. - Additional code size - Additional code complexity These are general concerns of all new features. It is possible to split the code out into separate codepaths (the 2.4 async read/write paths were completely new), but that cuts down on code sharing between the traditional sync read/writes and async code. If that is a requirement for merging, then they certainly could be split out and grown in a separate aio module, but that leads to other maintenence headches. The flip side of this question is that we already have O_DIRECT and all of its associated overhead, yet the vast majority of systems don't use it in the course of day to day operation. Maybe we should have config options for these things, but where does the line get drawn? - Significantly degrades collective understanding of how the VFS works. That can be improved through the use of debugging options to teach people that aio_* functions should not block, which is the only real difference between async and non-async functions -- if you'd block, return -EIOCBRETRY instead. Pros: - Unclear. We already have a number of users demanding buffered filesystem aio -- the UML patches to use aio just went in. Samba is able to make use of aio. There are lots of high performance server applications which require aio and filesystem caching (think iSCSI servers, web servers/caches). Right now the only way to do that is via threads, which brings into play a lot of other overhead. AIO is one of the last areas in which we don't provide a suitable implementation for use in normal applications, only highly specialised database users. -ben - 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.6.13-mm1
Andrew wrote So then I was asked to include an explanation with the drop message and that all got too hard so I turned them off. turns them back on again Dang it, Andrew. It didn't have to be hard. Just adding a boiler plate sentence to all the drop messages saying something like: If I just sent the patch to Linus, that is probably why I dropped it here. That should be enough of a clue for most folks. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - 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.6.13-mm1
Paul Jackson [EMAIL PROTECTED] wrote: Andrew wrote So then I was asked to include an explanation with the drop message and that all got too hard so I turned them off. turns them back on again Dang it, Andrew. It didn't have to be hard. I got three unhappy emails and turned it off again ;) Just adding a boiler plate sentence to all the drop messages saying something like: If I just sent the patch to Linus, that is probably why I dropped it here. That should be enough of a clue for most folks. OK.. - 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.6.13-mm1
On 9/7/05, Paul Jackson [EMAIL PROTECTED] wrote: Andrew wrote So then I was asked to include an explanation with the drop message and that all got too hard so I turned them off. turns them back on again Dang it, Andrew. It didn't have to be hard. Just adding a boiler plate sentence to all the drop messages saying something like: If I just sent the patch to Linus, that is probably why I dropped it here. That should be enough of a clue for most folks. I agree completely. Something like that would be just fine for the patches that have been sent on to Linus. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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.6.13-mm1
Jesper wrote: Something like that would be just fine for the patches that have been sent on to Linus. No - not just the patches sent to Linus - that's a burden on Andrew to separate things out. Andrew can put the boiler plate statement on _all_ drop messages If I just sent the patch to Linus, that is probably why I dropped it here. At the very least, he gets to cuss us out for not being able to read, instead of not being able to associate the 'patch to Linus' message with the 'drop' message a few hours later. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - 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-usb-devel] Re: 2.6.13-mm1
Hi Alan, On 3/09/2005 3:19 a.m., Alan Stern wrote: On Thu, 1 Sep 2005, Andrew Morton wrote: Reuben Farrelly <[EMAIL PROTECTED]> wrote: I'm also observing some USB messages logged: Sep 2 13:26:22 tornado kernel: usb 5-1: new full speed USB device using uhci_hcd and address 13 Sep 2 13:26:22 tornado kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x6204 Sep 2 13:26:23 tornado kernel: hub 5-0:1.0: port 1 disabled by hub (EMI?), re-enabling... This message means pretty much what it says: noise or something else caused the connection to be disabled. In theory this could be caused by a problem with the host controller, the cable, or the printer. Does this happen consistently with 2.6.13-mm1? Did it happen with 2.6.12? It may have just been a red herring, as I haven't had the problem appear since, nor had I seen it before then. I've done multiple reboots, plug and unplugs to test since and all have been OK. Thanks for taking the time to reply. reuben - 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.6.13-mm1: hangs during boot ...
Hi,
On 5/09/2005 4:32 a.m., James Bottomley wrote:
On Sun, 2005-09-04 at 01:24 +1200, Reuben Farrelly wrote:
I am seeing it fill up my messages log as it is logging 1 or so messages each
minute. I've emailed the SCSI maintainer James Bottomley twice about it but
had no response either time.
OK, can you try this ... it should confirm the theory if the messages go
away.
Thanks,
James
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -315,7 +315,7 @@ int scsi_execute(struct scsi_device *sde
req->sense = sense;
req->sense_len = 0;
req->timeout = timeout;
- req->flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL;
+ req->flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL | REQ_QUIET;
/*
* head injection *required* here otherwise quiesce won't work
@@ -927,17 +927,20 @@ void scsi_io_completion(struct scsi_cmnd
scsi_requeue_command(q, cmd);
return;
}
- printk(KERN_INFO "Device %s not ready.\n",
- req->rq_disk ? req->rq_disk->disk_name : "");
+ if (!(req->flags & REQ_QUIET))
+ dev_printk(KERN_INFO,
+ >device->sdev_gendev,
+ "Device not ready.\n");
cmd = scsi_end_request(cmd, 0, this_count, 1);
return;
case VOLUME_OVERFLOW:
- printk(KERN_INFO "Volume overflow <%d %d %d %d> CDB: ",
- cmd->device->host->host_no,
- (int)cmd->device->channel,
- (int)cmd->device->id, (int)cmd->device->lun);
- __scsi_print_command(cmd->data_cmnd);
- scsi_print_sense("", cmd);
+ if (!(req->flags & REQ_QUIET)) {
+ dev_printk(KERN_INFO,
+ >device->sdev_gendev,
+ "Volume overflow, CDB: ");
+ __scsi_print_command(cmd->data_cmnd);
+ scsi_print_sense("", cmd);
+ }
cmd = scsi_end_request(cmd, 0, block_bytes, 1);
return;
default:
@@ -954,15 +957,13 @@ void scsi_io_completion(struct scsi_cmnd
return;
}
if (result) {
- if (!(req->flags & REQ_SPECIAL))
- printk(KERN_INFO "SCSI error : <%d %d %d %d> return code
"
- "= 0x%x\n", cmd->device->host->host_no,
- cmd->device->channel,
- cmd->device->id,
- cmd->device->lun, result);
+ if (!(req->flags & REQ_QUIET)) {
+ dev_printk(KERN_INFO, >device->sdev_gendev,
+ "SCSI error: return code = 0x%x\n", result);
- if (driver_byte(result) & DRIVER_SENSE)
- scsi_print_sense("", cmd);
+ if (driver_byte(result) & DRIVER_SENSE)
+ scsi_print_sense("", cmd);
+ }
/*
* Mark a single buffer as not uptodate. Queue the remainder.
* We sometimes get this cruft in the event that a medium error
This patch fixes it, and there was no message during boot about not being
ready, nor after the machine had fully booted. Great ;-)
However, I did get an oops when warm booting the kernel, I suspect this may be
the oops that I get every now and then when warm rebooting, with no real
pattern, and possibly isn't related to the patch. As my serial console wasn't
set up at the time, I took a photo instead, at
http://www.reub.net/kernel/scsi-oops.jpg
Thanks
reuben
-
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.6.13-mm1: hangs during boot ...
Hi,
On 5/09/2005 4:32 a.m., James Bottomley wrote:
On Sun, 2005-09-04 at 01:24 +1200, Reuben Farrelly wrote:
I am seeing it fill up my messages log as it is logging 1 or so messages each
minute. I've emailed the SCSI maintainer James Bottomley twice about it but
had no response either time.
OK, can you try this ... it should confirm the theory if the messages go
away.
Thanks,
James
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -315,7 +315,7 @@ int scsi_execute(struct scsi_device *sde
req-sense = sense;
req-sense_len = 0;
req-timeout = timeout;
- req-flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL;
+ req-flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL | REQ_QUIET;
/*
* head injection *required* here otherwise quiesce won't work
@@ -927,17 +927,20 @@ void scsi_io_completion(struct scsi_cmnd
scsi_requeue_command(q, cmd);
return;
}
- printk(KERN_INFO Device %s not ready.\n,
- req-rq_disk ? req-rq_disk-disk_name : );
+ if (!(req-flags REQ_QUIET))
+ dev_printk(KERN_INFO,
+ cmd-device-sdev_gendev,
+ Device not ready.\n);
cmd = scsi_end_request(cmd, 0, this_count, 1);
return;
case VOLUME_OVERFLOW:
- printk(KERN_INFO Volume overflow %d %d %d %d CDB: ,
- cmd-device-host-host_no,
- (int)cmd-device-channel,
- (int)cmd-device-id, (int)cmd-device-lun);
- __scsi_print_command(cmd-data_cmnd);
- scsi_print_sense(, cmd);
+ if (!(req-flags REQ_QUIET)) {
+ dev_printk(KERN_INFO,
+ cmd-device-sdev_gendev,
+ Volume overflow, CDB: );
+ __scsi_print_command(cmd-data_cmnd);
+ scsi_print_sense(, cmd);
+ }
cmd = scsi_end_request(cmd, 0, block_bytes, 1);
return;
default:
@@ -954,15 +957,13 @@ void scsi_io_completion(struct scsi_cmnd
return;
}
if (result) {
- if (!(req-flags REQ_SPECIAL))
- printk(KERN_INFO SCSI error : %d %d %d %d return code
- = 0x%x\n, cmd-device-host-host_no,
- cmd-device-channel,
- cmd-device-id,
- cmd-device-lun, result);
+ if (!(req-flags REQ_QUIET)) {
+ dev_printk(KERN_INFO, cmd-device-sdev_gendev,
+ SCSI error: return code = 0x%x\n, result);
- if (driver_byte(result) DRIVER_SENSE)
- scsi_print_sense(, cmd);
+ if (driver_byte(result) DRIVER_SENSE)
+ scsi_print_sense(, cmd);
+ }
/*
* Mark a single buffer as not uptodate. Queue the remainder.
* We sometimes get this cruft in the event that a medium error
This patch fixes it, and there was no message during boot about not being
ready, nor after the machine had fully booted. Great ;-)
However, I did get an oops when warm booting the kernel, I suspect this may be
the oops that I get every now and then when warm rebooting, with no real
pattern, and possibly isn't related to the patch. As my serial console wasn't
set up at the time, I took a photo instead, at
http://www.reub.net/kernel/scsi-oops.jpg
Thanks
reuben
-
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-usb-devel] Re: 2.6.13-mm1
Hi Alan, On 3/09/2005 3:19 a.m., Alan Stern wrote: On Thu, 1 Sep 2005, Andrew Morton wrote: Reuben Farrelly [EMAIL PROTECTED] wrote: I'm also observing some USB messages logged: Sep 2 13:26:22 tornado kernel: usb 5-1: new full speed USB device using uhci_hcd and address 13 Sep 2 13:26:22 tornado kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x6204 Sep 2 13:26:23 tornado kernel: hub 5-0:1.0: port 1 disabled by hub (EMI?), re-enabling... This message means pretty much what it says: noise or something else caused the connection to be disabled. In theory this could be caused by a problem with the host controller, the cable, or the printer. Does this happen consistently with 2.6.13-mm1? Did it happen with 2.6.12? It may have just been a red herring, as I haven't had the problem appear since, nor had I seen it before then. I've done multiple reboots, plug and unplugs to test since and all have been OK. Thanks for taking the time to reply. reuben - 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.6.13-mm1
On 9/4/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > Jesper Juhl <[EMAIL PROTECTED]> wrote: > > > > I'm wondering if it would be too much trouble to have a mm-drops list > > similar to the mm-commits list. > > Well I was sending drop messages to mm-commits, but lots of people went > "Waah, why did you drop my patch?". A few hours after they'd been cc'ed as > the patch went in to Linus! So then I was asked to include an explanation > with the drop message and that all got too hard so I turned them off. > If patches dropped due to being merged in mainline were then commented with a simple "merged in mainline" note, surely that would keep the "Waah .." mails out of your mailbox. :-) > > > > I also like to keep track of what patches of mine get accepted and > > subsequently dropped. > > As I say, the way to do this is via your quilt series file. > Hmm, I've been looking at quilt, but never really got to the point of actually starting to use it - guess I should get started on that. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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.6.13-mm1
Jesper Juhl <[EMAIL PROTECTED]> wrote: > > I'm wondering if it would be too much trouble to have a mm-drops list > similar to the mm-commits list. Well I was sending drop messages to mm-commits, but lots of people went "Waah, why did you drop my patch?". A few hours after they'd been cc'ed as the patch went in to Linus! So then I was asked to include an explanation with the drop message and that all got too hard so I turned them off. > I also like to keep track of what patches of mine get accepted and > subsequently dropped. As I say, the way to do this is via your quilt series file. - 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.6.13-mm1
On 9/3/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote: > > > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Andrew, > > > > > > > > it seems you dropped > > > > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's > > > > zero mentioning of this dropping in the changelog of 2.6.13-mm1. > > > > > > > > Can you explain why you did silently drop it? > > > > > > It spat rejects and when I looked at the putative removal date I just > > > didn't believe it anyway. Send a rediffed one if you like, but > > > October 2005 is unrealistic. > > > > That the date is no longer realistic is clear. What disappoints me is > > that you didn't mention in the changelog of 2.6.13-mm1 where I'd have > > noticed it. > > Sometimes I can't be bothered getting into email threads over relatively > unimportant stuff. Usually it's related to the number of bugs we have. > > > It semms I need my own bookkeeping of patches I sent that are in -mm to > > notice when they get lost. > > This is called "quilt". > I'm wondering if it would be too much trouble to have a mm-drops list similar to the mm-commits list. I also like to keep track of what patches of mine get accepted and subsequently dropped. What I'm thinking is that it seems you have the mails to mm-commit pretty much automated (I may be wrong, but it seems that way to me). If they are indeed automated, then how hard would it be to set your end up to automatically send a mail to the same people who got the original mm-commits mail + send it to a central mm-drops list that those of us who care about this could subscribe to? As far as I'm concerned the mails wouldn't even need to contain a reason (although one would of course be nice) - just a mail stating the fact that patch xyz was dropped from the mm tree would be great. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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.6.13-mm1
On Sat, Sep 03, 2005 at 01:06:32PM -0700, Andrew Morton wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote: > > > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Andrew, > > > > > > > > it seems you dropped > > > > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's > > > > zero mentioning of this dropping in the changelog of 2.6.13-mm1. > > > > > > > > Can you explain why you did silently drop it? > > > > > > It spat rejects and when I looked at the putative removal date I just > > > didn't believe it anyway. Send a rediffed one if you like, but > > > October 2005 is unrealistic. > > > > That the date is no longer realistic is clear. What disappoints me is > > that you didn't mention in the changelog of 2.6.13-mm1 where I'd have > > noticed it. > > Sometimes I can't be bothered getting into email threads over relatively > unimportant stuff. Usually it's related to the number of bugs we have. This is not about email threads. You send a changelog when you announce a new -mm kernel. Why didn't you simply mention that you dropped this patch due to rejects in the changelog you are sending? > > It semms I need my own bookkeeping of patches I sent that are in -mm to > > notice when they get lost. > > This is called "quilt". > > > The only positive side effect of this is that > > I can use this to push you harder to forward some patches of me to Linus > > that stay unforwarded in -mm for several months... > > A single release cycle is 2-3 months. And I'm talking about patches waiting in -mm for more than 5 months. > I'll probably be dropping some of the patches which unexport symbols, btw. > ANy ones which aren't really, really obvious. We have a process for this. You accept patches into -mm, and without any new issues with these patches you tell me more than five months later "I'll probably be dropping some of the patches which unexport symbols, btw."? If this is how my work is appreciated here I'll better stop wasting part of my spare time and unsubscribe from linux-kernel. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.6.13-mm1: hangs during boot ...
On Sun, 2005-09-04 at 01:24 +1200, Reuben Farrelly wrote:
> I am seeing it fill up my messages log as it is logging 1 or so messages each
> minute. I've emailed the SCSI maintainer James Bottomley twice about it but
> had no response either time.
OK, can you try this ... it should confirm the theory if the messages go
away.
Thanks,
James
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -315,7 +315,7 @@ int scsi_execute(struct scsi_device *sde
req->sense = sense;
req->sense_len = 0;
req->timeout = timeout;
- req->flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL;
+ req->flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL | REQ_QUIET;
/*
* head injection *required* here otherwise quiesce won't work
@@ -927,17 +927,20 @@ void scsi_io_completion(struct scsi_cmnd
scsi_requeue_command(q, cmd);
return;
}
- printk(KERN_INFO "Device %s not ready.\n",
- req->rq_disk ? req->rq_disk->disk_name : "");
+ if (!(req->flags & REQ_QUIET))
+ dev_printk(KERN_INFO,
+ >device->sdev_gendev,
+ "Device not ready.\n");
cmd = scsi_end_request(cmd, 0, this_count, 1);
return;
case VOLUME_OVERFLOW:
- printk(KERN_INFO "Volume overflow <%d %d %d %d> CDB: ",
- cmd->device->host->host_no,
- (int)cmd->device->channel,
- (int)cmd->device->id, (int)cmd->device->lun);
- __scsi_print_command(cmd->data_cmnd);
- scsi_print_sense("", cmd);
+ if (!(req->flags & REQ_QUIET)) {
+ dev_printk(KERN_INFO,
+ >device->sdev_gendev,
+ "Volume overflow, CDB: ");
+ __scsi_print_command(cmd->data_cmnd);
+ scsi_print_sense("", cmd);
+ }
cmd = scsi_end_request(cmd, 0, block_bytes, 1);
return;
default:
@@ -954,15 +957,13 @@ void scsi_io_completion(struct scsi_cmnd
return;
}
if (result) {
- if (!(req->flags & REQ_SPECIAL))
- printk(KERN_INFO "SCSI error : <%d %d %d %d> return
code "
- "= 0x%x\n", cmd->device->host->host_no,
- cmd->device->channel,
- cmd->device->id,
- cmd->device->lun, result);
+ if (!(req->flags & REQ_QUIET)) {
+ dev_printk(KERN_INFO, >device->sdev_gendev,
+ "SCSI error: return code = 0x%x\n", result);
- if (driver_byte(result) & DRIVER_SENSE)
- scsi_print_sense("", cmd);
+ if (driver_byte(result) & DRIVER_SENSE)
+ scsi_print_sense("", cmd);
+ }
/*
* Mark a single buffer as not uptodate. Queue the remainder.
* We sometimes get this cruft in the event that a medium error
-
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.6.13-mm1: PCMCIA problem
Hi! > > > One more piece of information. This is the one that loops: > > > > > > echo 30 > /sys/class/firmware/timeout > > > > Try echo -n ... > > Or revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch. > Obviously if you write 30\n and the write returns 2 then the shell will > then try to write the \n. That returns zero and the shell tries again, ad > infinitum. Can you revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch, instead? Kernel should not provide "nice" interface. Striping trailing whitespace is wrong, just teach users to use sysfs right. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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.6.13-mm1
On Thu, Sep 01, 2005 at 03:55:42AM -0700 Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/ > I got: <7>Dead loop on netdevice eth0, fix it urgently! When using netconsole and printing out some information from kernel to console. The box uses: [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/ :00:0f.0 Ethernet controller: Linksys NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) Relevant config: CONFIG_NET_TULIP=y # CONFIG_DE2104X is not set CONFIG_TULIP=y CONFIG_TULIP_MWI=y # CONFIG_TULIP_MMIO is not set CONFIG_TULIP_NAPI=y Matt, on another box I got some irq off hangs that went away when removing netconsole from the .config on a box with 3c59x. Is this known? The problem is getting backtraces when netconsole is active, but the last thing I see before the box goes is that some carrier is up... - 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.6.13-mm1
On Thu, Sep 01, 2005 at 03:55:42AM -0700 Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/ I got: 7Dead loop on netdevice eth0, fix it urgently! When using netconsole and printing out some information from kernel to console. The box uses: [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/ :00:0f.0 Ethernet controller: Linksys NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) Relevant config: CONFIG_NET_TULIP=y # CONFIG_DE2104X is not set CONFIG_TULIP=y CONFIG_TULIP_MWI=y # CONFIG_TULIP_MMIO is not set CONFIG_TULIP_NAPI=y Matt, on another box I got some irq off hangs that went away when removing netconsole from the .config on a box with 3c59x. Is this known? The problem is getting backtraces when netconsole is active, but the last thing I see before the box goes is that some carrier is up... - 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.6.13-mm1: PCMCIA problem
Hi! One more piece of information. This is the one that loops: echo 30 /sys/class/firmware/timeout Try echo -n ... Or revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch. Obviously if you write 30\n and the write returns 2 then the shell will then try to write the \n. That returns zero and the shell tries again, ad infinitum. Can you revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch, instead? Kernel should not provide nice interface. Striping trailing whitespace is wrong, just teach users to use sysfs right. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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.6.13-mm1: hangs during boot ...
On Sun, 2005-09-04 at 01:24 +1200, Reuben Farrelly wrote:
I am seeing it fill up my messages log as it is logging 1 or so messages each
minute. I've emailed the SCSI maintainer James Bottomley twice about it but
had no response either time.
OK, can you try this ... it should confirm the theory if the messages go
away.
Thanks,
James
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -315,7 +315,7 @@ int scsi_execute(struct scsi_device *sde
req-sense = sense;
req-sense_len = 0;
req-timeout = timeout;
- req-flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL;
+ req-flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL | REQ_QUIET;
/*
* head injection *required* here otherwise quiesce won't work
@@ -927,17 +927,20 @@ void scsi_io_completion(struct scsi_cmnd
scsi_requeue_command(q, cmd);
return;
}
- printk(KERN_INFO Device %s not ready.\n,
- req-rq_disk ? req-rq_disk-disk_name : );
+ if (!(req-flags REQ_QUIET))
+ dev_printk(KERN_INFO,
+ cmd-device-sdev_gendev,
+ Device not ready.\n);
cmd = scsi_end_request(cmd, 0, this_count, 1);
return;
case VOLUME_OVERFLOW:
- printk(KERN_INFO Volume overflow %d %d %d %d CDB: ,
- cmd-device-host-host_no,
- (int)cmd-device-channel,
- (int)cmd-device-id, (int)cmd-device-lun);
- __scsi_print_command(cmd-data_cmnd);
- scsi_print_sense(, cmd);
+ if (!(req-flags REQ_QUIET)) {
+ dev_printk(KERN_INFO,
+ cmd-device-sdev_gendev,
+ Volume overflow, CDB: );
+ __scsi_print_command(cmd-data_cmnd);
+ scsi_print_sense(, cmd);
+ }
cmd = scsi_end_request(cmd, 0, block_bytes, 1);
return;
default:
@@ -954,15 +957,13 @@ void scsi_io_completion(struct scsi_cmnd
return;
}
if (result) {
- if (!(req-flags REQ_SPECIAL))
- printk(KERN_INFO SCSI error : %d %d %d %d return
code
- = 0x%x\n, cmd-device-host-host_no,
- cmd-device-channel,
- cmd-device-id,
- cmd-device-lun, result);
+ if (!(req-flags REQ_QUIET)) {
+ dev_printk(KERN_INFO, cmd-device-sdev_gendev,
+ SCSI error: return code = 0x%x\n, result);
- if (driver_byte(result) DRIVER_SENSE)
- scsi_print_sense(, cmd);
+ if (driver_byte(result) DRIVER_SENSE)
+ scsi_print_sense(, cmd);
+ }
/*
* Mark a single buffer as not uptodate. Queue the remainder.
* We sometimes get this cruft in the event that a medium error
-
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.6.13-mm1
On Sat, Sep 03, 2005 at 01:06:32PM -0700, Andrew Morton wrote: Adrian Bunk [EMAIL PROTECTED] wrote: On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote: Adrian Bunk [EMAIL PROTECTED] wrote: Hi Andrew, it seems you dropped schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's zero mentioning of this dropping in the changelog of 2.6.13-mm1. Can you explain why you did silently drop it? It spat rejects and when I looked at the putative removal date I just didn't believe it anyway. Send a rediffed one if you like, but October 2005 is unrealistic. That the date is no longer realistic is clear. What disappoints me is that you didn't mention in the changelog of 2.6.13-mm1 where I'd have noticed it. Sometimes I can't be bothered getting into email threads over relatively unimportant stuff. Usually it's related to the number of bugs we have. This is not about email threads. You send a changelog when you announce a new -mm kernel. Why didn't you simply mention that you dropped this patch due to rejects in the changelog you are sending? It semms I need my own bookkeeping of patches I sent that are in -mm to notice when they get lost. This is called quilt. The only positive side effect of this is that I can use this to push you harder to forward some patches of me to Linus that stay unforwarded in -mm for several months... A single release cycle is 2-3 months. And I'm talking about patches waiting in -mm for more than 5 months. I'll probably be dropping some of the patches which unexport symbols, btw. ANy ones which aren't really, really obvious. We have a process for this. You accept patches into -mm, and without any new issues with these patches you tell me more than five months later I'll probably be dropping some of the patches which unexport symbols, btw.? If this is how my work is appreciated here I'll better stop wasting part of my spare time and unsubscribe from linux-kernel. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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.6.13-mm1
On 9/3/05, Andrew Morton [EMAIL PROTECTED] wrote: Adrian Bunk [EMAIL PROTECTED] wrote: On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote: Adrian Bunk [EMAIL PROTECTED] wrote: Hi Andrew, it seems you dropped schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's zero mentioning of this dropping in the changelog of 2.6.13-mm1. Can you explain why you did silently drop it? It spat rejects and when I looked at the putative removal date I just didn't believe it anyway. Send a rediffed one if you like, but October 2005 is unrealistic. That the date is no longer realistic is clear. What disappoints me is that you didn't mention in the changelog of 2.6.13-mm1 where I'd have noticed it. Sometimes I can't be bothered getting into email threads over relatively unimportant stuff. Usually it's related to the number of bugs we have. It semms I need my own bookkeeping of patches I sent that are in -mm to notice when they get lost. This is called quilt. I'm wondering if it would be too much trouble to have a mm-drops list similar to the mm-commits list. I also like to keep track of what patches of mine get accepted and subsequently dropped. What I'm thinking is that it seems you have the mails to mm-commit pretty much automated (I may be wrong, but it seems that way to me). If they are indeed automated, then how hard would it be to set your end up to automatically send a mail to the same people who got the original mm-commits mail + send it to a central mm-drops list that those of us who care about this could subscribe to? As far as I'm concerned the mails wouldn't even need to contain a reason (although one would of course be nice) - just a mail stating the fact that patch xyz was dropped from the mm tree would be great. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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.6.13-mm1
Jesper Juhl [EMAIL PROTECTED] wrote: I'm wondering if it would be too much trouble to have a mm-drops list similar to the mm-commits list. Well I was sending drop messages to mm-commits, but lots of people went Waah, why did you drop my patch?. A few hours after they'd been cc'ed as the patch went in to Linus! So then I was asked to include an explanation with the drop message and that all got too hard so I turned them off. turns them back on again I also like to keep track of what patches of mine get accepted and subsequently dropped. As I say, the way to do this is via your quilt series file. - 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.6.13-mm1
On 9/4/05, Andrew Morton [EMAIL PROTECTED] wrote: Jesper Juhl [EMAIL PROTECTED] wrote: I'm wondering if it would be too much trouble to have a mm-drops list similar to the mm-commits list. Well I was sending drop messages to mm-commits, but lots of people went Waah, why did you drop my patch?. A few hours after they'd been cc'ed as the patch went in to Linus! So then I was asked to include an explanation with the drop message and that all got too hard so I turned them off. If patches dropped due to being merged in mainline were then commented with a simple merged in mainline note, surely that would keep the Waah .. mails out of your mailbox. :-) turns them back on again I also like to keep track of what patches of mine get accepted and subsequently dropped. As I say, the way to do this is via your quilt series file. Hmm, I've been looking at quilt, but never really got to the point of actually starting to use it - guess I should get started on that. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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.6.13-mm1: hangs during boot ...
Brown, Len wrote: Please then try the latest ACPI patch here: > http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches /release/2.6.13/acpi-20050902-2.6.13.diff.gz > It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig > that you can ignore. > > If this works, then we munged git-acpi.patch in 2.6.13-mm1 somehow. There were no problems with this patch applied. So it looks like the munge theory is correct. That diff is significantly different from the diff I plucked from master.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 .git#test for 2.6.13-mm1. Doing (patch -R | grep FAILED) on 2.6.13-mm1 says: Right. 2.6.13/acpi-20050902-2.6.13.diff.gz is newers than 2.6.13-rc1's git-acpi.patch 2.6.13/acpi-20050815-2.6.13.diff.gz is a closer match -- though not exact. Peter, it might be illustrative if you have a moment if you can also test 2.6.13/acpi-20050815-2.6.13.diff.gz all by itself. If it fails, It does. then I broke -mm1 with acpi-20050815-2.6.13.diff.gz, but fixed it by acpi-20050902-2.6.13.diff.gz. So you did. If it succeeds, then the issue lies in the relatively small delta between acpi-20050815-2.6.13.diff.gz 2.6.13-mm1's git-acpi.patch. thanks, -Len My pleasure Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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.6.13-mm1
Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote: > > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > > Hi Andrew, > > > > > > it seems you dropped > > > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's > > > zero mentioning of this dropping in the changelog of 2.6.13-mm1. > > > > > > Can you explain why you did silently drop it? > > > > It spat rejects and when I looked at the putative removal date I just > > didn't believe it anyway. Send a rediffed one if you like, but > > October 2005 is unrealistic. > > That the date is no longer realistic is clear. What disappoints me is > that you didn't mention in the changelog of 2.6.13-mm1 where I'd have > noticed it. Sometimes I can't be bothered getting into email threads over relatively unimportant stuff. Usually it's related to the number of bugs we have. > It semms I need my own bookkeeping of patches I sent that are in -mm to > notice when they get lost. This is called "quilt". > The only positive side effect of this is that > I can use this to push you harder to forward some patches of me to Linus > that stay unforwarded in -mm for several months... A single release cycle is 2-3 months. I'll probably be dropping some of the patches which unexport symbols, btw. ANy ones which aren't really, really obvious. We have a process for this. - 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.6.13-mm1
On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > Hi Andrew, > > > > it seems you dropped > > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's > > zero mentioning of this dropping in the changelog of 2.6.13-mm1. > > > > Can you explain why you did silently drop it? > > It spat rejects and when I looked at the putative removal date I just > didn't believe it anyway. Send a rediffed one if you like, but > October 2005 is unrealistic. That the date is no longer realistic is clear. What disappoints me is that you didn't mention in the changelog of 2.6.13-mm1 where I'd have noticed it. It semms I need my own bookkeeping of patches I sent that are in -mm to notice when they get lost. The only positive side effect of this is that I can use this to push you harder to forward some patches of me to Linus that stay unforwarded in -mm for several months... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.6.13-mm1
Adrian Bunk <[EMAIL PROTECTED]> wrote: > > Hi Andrew, > > it seems you dropped > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's > zero mentioning of this dropping in the changelog of 2.6.13-mm1. > > Can you explain why you did silently drop it? > It spat rejects and when I looked at the putative removal date I just didn't believe it anyway. Send a rediffed one if you like, but October 2005 is unrealistic. - 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.6.13-mm1 login fails
From: "Brown, Len" <[EMAIL PROTECTED]> Date: Sat, 3 Sep 2005 12:58:15 -0400 > CONFIG_AUDIT=y indeed did the trick. > > When will I be able to delete CONFIG_AUDIT from my kernel again? It's a regression we accidently added to the netlink socket family, we will fix it. But please use the workaround of enabling CONFIG_AUDIT until we fix it, thanks. - 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.6.13-mm1: hangs during boot ...
On Sat, 2005-09-03 at 23:51 +1000, Peter Williams wrote: > > Are you seeing this "Device not ready" message appear over and over, or > > just the once? > > Just the once. OK, I finally have a theory about this. It's the everything goes via bios code. Previously there were several levels at which commands could exit the SCSI stack; now we make everything go via bios, so they all come out at the top. get_capabilities() in sr.c is sending a TEST_UNIT_READY which will get NOT_READY back. Previously this was completing before it got to scsi_io_completion(); now it doesn't. There must be quite a few cases like this. The best fix is probably to use and respect REQ_QUIET for internally generated commands. James - 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/
2.6.13-mm1 login fails (RE: 2.6.13-mm1: hangs during boot ...)
>As for the inability to log in, this bug may be relevant, >given I also had >that problem: > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422 > >There are fixes in the pipeline for util-linux audit >interaction in Fedora as >well. I know because I reported those too ;) > >> after the scsi initialization which I don't normally see. >I've attached >> the scsi initialization output. The PF_NETLINK error >messages after the >> login prompt in this output are created whenever I try to log in or >> connect via ssh. > >The workaround by enabling audit support, but obviously a >better fix is in the >pipeline.. > >I'm surprised more people aren't discovering these >'interactions' due to >having audit not turned on. Does everyone build audit into >their kernels? This sure made my FC4 test boxes hard to use! CONFIG_AUDIT=y indeed did the trick. When will I be able to delete CONFIG_AUDIT from my kernel again? thanks -Len - 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.6.13-mm1: hangs during boot ...
>> > Please then try the latest ACPI patch here: >> > >http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches >/release/2.6.13/acpi-20050902-2.6.13.diff.gz >> > It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig >> > that you can ignore. >> > >> > If this works, then we munged git-acpi.patch in >2.6.13-mm1 somehow. >> >> There were no problems with this patch applied. So it >looks like the >> munge theory is correct. > >That diff is significantly different from the diff I plucked from >master.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 >.git#test >for 2.6.13-mm1. > >Doing (patch -R | grep FAILED) on 2.6.13-mm1 says: Right. 2.6.13/acpi-20050902-2.6.13.diff.gz is newers than 2.6.13-rc1's git-acpi.patch 2.6.13/acpi-20050815-2.6.13.diff.gz is a closer match -- though not exact. Peter, it might be illustrative if you have a moment if you can also test 2.6.13/acpi-20050815-2.6.13.diff.gz all by itself. If it fails, then I broke -mm1 with acpi-20050815-2.6.13.diff.gz, but fixed it by acpi-20050902-2.6.13.diff.gz. If it succeeds, then the issue lies in the relatively small delta between acpi-20050815-2.6.13.diff.gz 2.6.13-mm1's git-acpi.patch. thanks, -Len - 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.6.13-mm1: hangs during boot ...
Reuben Farrelly wrote: Hi Peter, On 3/09/2005 4:59 a.m., Peter Williams wrote: Brown, Len wrote: [ 279.662960] [] wait_for_completion+0xa4/0x110 possibly a missing interrupt? CONFIG_ACPI=y any difference if booted with "acpi=off" or "acpi=noirq"? Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a "device not ready" message Are you seeing this "Device not ready" message appear over and over, or just the once? Just the once. I am seeing it fill up my messages log as it is logging 1 or so messages each minute. I've emailed the SCSI maintainer James Bottomley twice about it but had no response either time. The SCSI device I have is: Sep 3 22:14:40 tornado kernel: Vendor: SONY Model: CD-RW CRX145S Rev: 1.0b As for the inability to log in, this bug may be relevant, given I also had that problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422 There are fixes in the pipeline for util-linux audit interaction in Fedora as well. I know because I reported those too ;) after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. The workaround by enabling audit support, but obviously a better fix is in the pipeline.. I'm surprised more people aren't discovering these 'interactions' due to having audit not turned on. Does everyone build audit into their kernels? reuben -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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.6.13-mm1: hangs during boot ...
Hi Peter, On 3/09/2005 4:59 a.m., Peter Williams wrote: Brown, Len wrote: [ 279.662960] [] wait_for_completion+0xa4/0x110 possibly a missing interrupt? CONFIG_ACPI=y any difference if booted with "acpi=off" or "acpi=noirq"? Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a "device not ready" message Are you seeing this "Device not ready" message appear over and over, or just the once? I am seeing it fill up my messages log as it is logging 1 or so messages each minute. I've emailed the SCSI maintainer James Bottomley twice about it but had no response either time. The SCSI device I have is: Sep 3 22:14:40 tornado kernel: Vendor: SONY Model: CD-RW CRX145S Rev: 1.0b As for the inability to log in, this bug may be relevant, given I also had that problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422 There are fixes in the pipeline for util-linux audit interaction in Fedora as well. I know because I reported those too ;) after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. The workaround by enabling audit support, but obviously a better fix is in the pipeline.. I'm surprised more people aren't discovering these 'interactions' due to having audit not turned on. Does everyone build audit into their kernels? reuben - 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.6.13-mm1
Hi Andrew, it seems you dropped schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's zero mentioning of this dropping in the changelog of 2.6.13-mm1. Can you explain why you did silently drop it? TIA Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.6.13-mm1: hangs during boot ...
Peter Williams <[EMAIL PROTECTED]> wrote: > > > Please then try the latest ACPI patch here: > > > http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.13/acpi-20050902-2.6.13.diff.gz > > It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig > > that you can ignore. > > > > If this works, then we munged git-acpi.patch in 2.6.13-mm1 somehow. > > There were no problems with this patch applied. So it looks like the > munge theory is correct. That diff is significantly different from the diff I plucked from master.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test for 2.6.13-mm1. Doing (patch -R | grep FAILED) on 2.6.13-mm1 says: Hunk #3 FAILED at 356. 1 out of 3 hunks FAILED -- saving rejects to file arch/ia64/Kconfig.rej Hunk #6 FAILED at 190. Hunk #8 FAILED at 221. Hunk #10 FAILED at 254. Hunk #11 FAILED at 357. Hunk #15 FAILED at 474. Hunk #17 FAILED at 569. 6 out of 17 hunks FAILED -- saving rejects to file drivers/acpi/dispatcher/dsmethod.c.rej Hunk #19 FAILED at 468. Hunk #29 FAILED at 701. 2 out of 38 hunks FAILED -- saving rejects to file drivers/acpi/dispatcher/dswload.c.rej Hunk #14 FAILED at 321. Hunk #43 FAILED at 1159. 2 out of 44 hunks FAILED -- saving rejects to file drivers/acpi/osl.c.rej Hunk #17 FAILED at 1134. 1 out of 18 hunks FAILED -- saving rejects to file drivers/acpi/parser/psparse.c.rej Hunk #3 FAILED at 74. 1 out of 3 hunks FAILED -- saving rejects to file drivers/acpi/parser/psxface.c.rej Hunk #1 FAILED at 35. 1 out of 15 hunks FAILED -- saving rejects to file drivers/acpi/pci_bind.c.rej Hunk #5 FAILED at 220. Hunk #15 FAILED at 412. Hunk #16 FAILED at 425. Hunk #17 FAILED at 446. Hunk #19 FAILED at 484. 5 out of 36 hunks FAILED -- saving rejects to file drivers/acpi/processor_core.c.rej Hunk #1 FAILED at 41. Hunk #2 FAILED at 71. Hunk #4 FAILED at -55. Hunk #5 FAILED at 30. Hunk #6 FAILED at 40. Hunk #7 FAILED at 69. Hunk #9 FAILED at 317. Hunk #10 FAILED at 344. Hunk #12 FAILED at 289. Hunk #14 FAILED at 523. Hunk #15 FAILED at 607. Hunk #16 FAILED at 618. Hunk #17 FAILED at 645. Hunk #19 FAILED at 534. Hunk #20 FAILED at 686. Hunk #22 FAILED at 916. Hunk #23 FAILED at 968. Hunk #25 FAILED at 881. Hunk #26 FAILED at 891. Hunk #29 FAILED at 953. 20 out of 29 hunks FAILED -- saving rejects to file drivers/acpi/resources/rsaddr.c.rej Hunk #11 FAILED at 289. Hunk #16 FAILED at 407. Hunk #17 FAILED at 425. Hunk #18 FAILED at 434. Hunk #20 FAILED at 470. Hunk #21 FAILED at 527. 6 out of 21 hunks FAILED -- saving rejects to file drivers/acpi/resources/rsirq.c.rej Hunk #27 FAILED at 553. 1 out of 61 hunks FAILED -- saving rejects to file drivers/acpi/scan.c.rej Hunk #1 FAILED at 41. 1 out of 34 hunks FAILED -- saving rejects to file drivers/acpi/utilities/utmisc.c.rej Hunk #5 FAILED at 291. 1 out of 76 hunks FAILED -- saving rejects to file drivers/acpi/video.c.rej Hunk #2 FAILED at 64. 1 out of 8 hunks FAILED -- saving rejects to file include/acpi/acconfig.h.rej Hunk #1 FAILED at 41. 1 out of 1 hunk FAILED -- saving rejects to file include/acpi/acdispat.h.rej Hunk #29 FAILED at 1078. Hunk #30 FAILED at 1240. 2 out of 31 hunks FAILED -- saving rejects to file include/acpi/actypes.h.rej - 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.6.13-mm1: hangs during boot ...
Len Brown wrote: On Sat, 2005-09-03 at 03:18 -0400, Peter Williams wrote: http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/broken-out/git-acpi.patch I am able to confirm that the problem occurs with vanilla 2.5.13 after I apply the above patch. Thanks. Please then try the latest ACPI patch here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.13/acpi-20050902-2.6.13.diff.gz It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig that you can ignore. If this works, then we munged git-acpi.patch in 2.6.13-mm1 somehow. There were no problems with this patch applied. So it looks like the munge theory is correct. If this fails, then please confirm it still fails with pnpacpi=off if it still fails, then please open a bugzilla here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI component=config-interrupts build the failing kernel with CONFIG_ACPI_DEBUG=y boot it with "acpi=noirq" and attach the output from dmesg -s64000 lspci -vv cat /proc/interrupts acpidump, available in the latest pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ also include the dmesg -s64000 from the successful acpi-enabled 2.6.13 boot, along with its /proc/interrupts. If you have a serial console and can then capture the failing console log with "debug", that would be ideal. Where we got from there will depend what we see... thanks, -Len Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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.6.13-mm1: hangs during boot ...
On Sat, 2005-09-03 at 03:18 -0400, Peter Williams wrote: > > http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/broken-out/git-acpi.patch > >> > I am able to confirm that the problem occurs with vanilla 2.5.13 after > I apply the above patch. Thanks. Please then try the latest ACPI patch here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.13/acpi-20050902-2.6.13.diff.gz It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig that you can ignore. If this works, then we munged git-acpi.patch in 2.6.13-mm1 somehow. If this fails, then please confirm it still fails with pnpacpi=off if it still fails, then please open a bugzilla here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI component=config-interrupts build the failing kernel with CONFIG_ACPI_DEBUG=y boot it with "acpi=noirq" and attach the output from dmesg -s64000 lspci -vv cat /proc/interrupts acpidump, available in the latest pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ also include the dmesg -s64000 from the successful acpi-enabled 2.6.13 boot, along with its /proc/interrupts. If you have a serial console and can then capture the failing console log with "debug", that would be ideal. Where we got from there will depend what we see... thanks, -Len - 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.6.13-mm1: hangs during boot ...
Peter Williams wrote: Brown, Len wrote: Brown, Len wrote: [ 279.662960] [] wait_for_completion+0xa4/0x110 possibly a missing interrupt? CONFIG_ACPI=y any difference if booted with "acpi=off" or "acpi=noirq"? Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a "device not ready" message after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. Please confirm that vanilla 2.6.13 has none of these symptoms. That's correct. 2.6.13 exhibits none of these symptoms. Please apply just the ACPI part of the 2.6.13-mm1 patch to see if these issues are caused by that or if they are caused by something else in the mm patch. http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/broken-out/git-acpi.patch OK. I'll get back to you shortly. I am able to confirm that the problem occurs with vanilla 2.5.13 after I apply the above patch. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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.6.13-mm1: hangs during boot ...
Brown, Len wrote: Brown, Len wrote: [ 279.662960] [] wait_for_completion+0xa4/0x110 possibly a missing interrupt? CONFIG_ACPI=y any difference if booted with "acpi=off" or "acpi=noirq"? Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a "device not ready" message after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. Please confirm that vanilla 2.6.13 has none of these symptoms. That's correct. 2.6.13 exhibits none of these symptoms. Please apply just the ACPI part of the 2.6.13-mm1 patch to see if these issues are caused by that or if they are caused by something else in the mm patch. http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/broken-out/git-acpi.patch OK. I'll get back to you shortly. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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.6.13-mm1: hangs during boot ...
Brown, Len wrote: Brown, Len wrote: [ 279.662960] [c02d5c74] wait_for_completion+0xa4/0x110 possibly a missing interrupt? CONFIG_ACPI=y any difference if booted with acpi=off or acpi=noirq? Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a device not ready message after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. Please confirm that vanilla 2.6.13 has none of these symptoms. That's correct. 2.6.13 exhibits none of these symptoms. Please apply just the ACPI part of the 2.6.13-mm1 patch to see if these issues are caused by that or if they are caused by something else in the mm patch. http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/broken-out/git-acpi.patch OK. I'll get back to you shortly. Peter -- Peter Williams [EMAIL PROTECTED] Learning, n. The kind of ignorance distinguishing the studious. -- Ambrose Bierce - 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.6.13-mm1: hangs during boot ...
Peter Williams wrote: Brown, Len wrote: Brown, Len wrote: [ 279.662960] [c02d5c74] wait_for_completion+0xa4/0x110 possibly a missing interrupt? CONFIG_ACPI=y any difference if booted with acpi=off or acpi=noirq? Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a device not ready message after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. Please confirm that vanilla 2.6.13 has none of these symptoms. That's correct. 2.6.13 exhibits none of these symptoms. Please apply just the ACPI part of the 2.6.13-mm1 patch to see if these issues are caused by that or if they are caused by something else in the mm patch. http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/broken-out/git-acpi.patch OK. I'll get back to you shortly. I am able to confirm that the problem occurs with vanilla 2.5.13 after I apply the above patch. Peter -- Peter Williams [EMAIL PROTECTED] Learning, n. The kind of ignorance distinguishing the studious. -- Ambrose Bierce - 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.6.13-mm1: hangs during boot ...
On Sat, 2005-09-03 at 03:18 -0400, Peter Williams wrote: http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/broken-out/git-acpi.patch I am able to confirm that the problem occurs with vanilla 2.5.13 after I apply the above patch. Thanks. Please then try the latest ACPI patch here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.13/acpi-20050902-2.6.13.diff.gz It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig that you can ignore. If this works, then we munged git-acpi.patch in 2.6.13-mm1 somehow. If this fails, then please confirm it still fails with pnpacpi=off if it still fails, then please open a bugzilla here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI component=config-interrupts build the failing kernel with CONFIG_ACPI_DEBUG=y boot it with acpi=noirq and attach the output from dmesg -s64000 lspci -vv cat /proc/interrupts acpidump, available in the latest pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ also include the dmesg -s64000 from the successful acpi-enabled 2.6.13 boot, along with its /proc/interrupts. If you have a serial console and can then capture the failing console log with debug, that would be ideal. Where we got from there will depend what we see... thanks, -Len - 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.6.13-mm1: hangs during boot ...
Len Brown wrote: On Sat, 2005-09-03 at 03:18 -0400, Peter Williams wrote: http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/broken-out/git-acpi.patch I am able to confirm that the problem occurs with vanilla 2.5.13 after I apply the above patch. Thanks. Please then try the latest ACPI patch here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.13/acpi-20050902-2.6.13.diff.gz It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig that you can ignore. If this works, then we munged git-acpi.patch in 2.6.13-mm1 somehow. There were no problems with this patch applied. So it looks like the munge theory is correct. If this fails, then please confirm it still fails with pnpacpi=off if it still fails, then please open a bugzilla here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI component=config-interrupts build the failing kernel with CONFIG_ACPI_DEBUG=y boot it with acpi=noirq and attach the output from dmesg -s64000 lspci -vv cat /proc/interrupts acpidump, available in the latest pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ also include the dmesg -s64000 from the successful acpi-enabled 2.6.13 boot, along with its /proc/interrupts. If you have a serial console and can then capture the failing console log with debug, that would be ideal. Where we got from there will depend what we see... thanks, -Len Peter -- Peter Williams [EMAIL PROTECTED] Learning, n. The kind of ignorance distinguishing the studious. -- Ambrose Bierce - 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.6.13-mm1: hangs during boot ...
Peter Williams [EMAIL PROTECTED] wrote: Please then try the latest ACPI patch here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.13/acpi-20050902-2.6.13.diff.gz It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig that you can ignore. If this works, then we munged git-acpi.patch in 2.6.13-mm1 somehow. There were no problems with this patch applied. So it looks like the munge theory is correct. That diff is significantly different from the diff I plucked from master.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test for 2.6.13-mm1. Doing (patch -R | grep FAILED) on 2.6.13-mm1 says: Hunk #3 FAILED at 356. 1 out of 3 hunks FAILED -- saving rejects to file arch/ia64/Kconfig.rej Hunk #6 FAILED at 190. Hunk #8 FAILED at 221. Hunk #10 FAILED at 254. Hunk #11 FAILED at 357. Hunk #15 FAILED at 474. Hunk #17 FAILED at 569. 6 out of 17 hunks FAILED -- saving rejects to file drivers/acpi/dispatcher/dsmethod.c.rej Hunk #19 FAILED at 468. Hunk #29 FAILED at 701. 2 out of 38 hunks FAILED -- saving rejects to file drivers/acpi/dispatcher/dswload.c.rej Hunk #14 FAILED at 321. Hunk #43 FAILED at 1159. 2 out of 44 hunks FAILED -- saving rejects to file drivers/acpi/osl.c.rej Hunk #17 FAILED at 1134. 1 out of 18 hunks FAILED -- saving rejects to file drivers/acpi/parser/psparse.c.rej Hunk #3 FAILED at 74. 1 out of 3 hunks FAILED -- saving rejects to file drivers/acpi/parser/psxface.c.rej Hunk #1 FAILED at 35. 1 out of 15 hunks FAILED -- saving rejects to file drivers/acpi/pci_bind.c.rej Hunk #5 FAILED at 220. Hunk #15 FAILED at 412. Hunk #16 FAILED at 425. Hunk #17 FAILED at 446. Hunk #19 FAILED at 484. 5 out of 36 hunks FAILED -- saving rejects to file drivers/acpi/processor_core.c.rej Hunk #1 FAILED at 41. Hunk #2 FAILED at 71. Hunk #4 FAILED at -55. Hunk #5 FAILED at 30. Hunk #6 FAILED at 40. Hunk #7 FAILED at 69. Hunk #9 FAILED at 317. Hunk #10 FAILED at 344. Hunk #12 FAILED at 289. Hunk #14 FAILED at 523. Hunk #15 FAILED at 607. Hunk #16 FAILED at 618. Hunk #17 FAILED at 645. Hunk #19 FAILED at 534. Hunk #20 FAILED at 686. Hunk #22 FAILED at 916. Hunk #23 FAILED at 968. Hunk #25 FAILED at 881. Hunk #26 FAILED at 891. Hunk #29 FAILED at 953. 20 out of 29 hunks FAILED -- saving rejects to file drivers/acpi/resources/rsaddr.c.rej Hunk #11 FAILED at 289. Hunk #16 FAILED at 407. Hunk #17 FAILED at 425. Hunk #18 FAILED at 434. Hunk #20 FAILED at 470. Hunk #21 FAILED at 527. 6 out of 21 hunks FAILED -- saving rejects to file drivers/acpi/resources/rsirq.c.rej Hunk #27 FAILED at 553. 1 out of 61 hunks FAILED -- saving rejects to file drivers/acpi/scan.c.rej Hunk #1 FAILED at 41. 1 out of 34 hunks FAILED -- saving rejects to file drivers/acpi/utilities/utmisc.c.rej Hunk #5 FAILED at 291. 1 out of 76 hunks FAILED -- saving rejects to file drivers/acpi/video.c.rej Hunk #2 FAILED at 64. 1 out of 8 hunks FAILED -- saving rejects to file include/acpi/acconfig.h.rej Hunk #1 FAILED at 41. 1 out of 1 hunk FAILED -- saving rejects to file include/acpi/acdispat.h.rej Hunk #29 FAILED at 1078. Hunk #30 FAILED at 1240. 2 out of 31 hunks FAILED -- saving rejects to file include/acpi/actypes.h.rej - 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.6.13-mm1
Hi Andrew, it seems you dropped schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's zero mentioning of this dropping in the changelog of 2.6.13-mm1. Can you explain why you did silently drop it? TIA Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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.6.13-mm1: hangs during boot ...
Hi Peter, On 3/09/2005 4:59 a.m., Peter Williams wrote: Brown, Len wrote: [ 279.662960] [c02d5c74] wait_for_completion+0xa4/0x110 possibly a missing interrupt? CONFIG_ACPI=y any difference if booted with acpi=off or acpi=noirq? Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a device not ready message Are you seeing this Device not ready message appear over and over, or just the once? I am seeing it fill up my messages log as it is logging 1 or so messages each minute. I've emailed the SCSI maintainer James Bottomley twice about it but had no response either time. The SCSI device I have is: Sep 3 22:14:40 tornado kernel: Vendor: SONY Model: CD-RW CRX145S Rev: 1.0b As for the inability to log in, this bug may be relevant, given I also had that problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422 There are fixes in the pipeline for util-linux audit interaction in Fedora as well. I know because I reported those too ;) after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. The workaround by enabling audit support, but obviously a better fix is in the pipeline.. I'm surprised more people aren't discovering these 'interactions' due to having audit not turned on. Does everyone build audit into their kernels? reuben - 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.6.13-mm1: hangs during boot ...
Reuben Farrelly wrote: Hi Peter, On 3/09/2005 4:59 a.m., Peter Williams wrote: Brown, Len wrote: [ 279.662960] [c02d5c74] wait_for_completion+0xa4/0x110 possibly a missing interrupt? CONFIG_ACPI=y any difference if booted with acpi=off or acpi=noirq? Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a device not ready message Are you seeing this Device not ready message appear over and over, or just the once? Just the once. I am seeing it fill up my messages log as it is logging 1 or so messages each minute. I've emailed the SCSI maintainer James Bottomley twice about it but had no response either time. The SCSI device I have is: Sep 3 22:14:40 tornado kernel: Vendor: SONY Model: CD-RW CRX145S Rev: 1.0b As for the inability to log in, this bug may be relevant, given I also had that problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422 There are fixes in the pipeline for util-linux audit interaction in Fedora as well. I know because I reported those too ;) after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. The workaround by enabling audit support, but obviously a better fix is in the pipeline.. I'm surprised more people aren't discovering these 'interactions' due to having audit not turned on. Does everyone build audit into their kernels? reuben -- Peter Williams [EMAIL PROTECTED] Learning, n. The kind of ignorance distinguishing the studious. -- Ambrose Bierce - 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.6.13-mm1: hangs during boot ...
Please then try the latest ACPI patch here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches /release/2.6.13/acpi-20050902-2.6.13.diff.gz It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig that you can ignore. If this works, then we munged git-acpi.patch in 2.6.13-mm1 somehow. There were no problems with this patch applied. So it looks like the munge theory is correct. That diff is significantly different from the diff I plucked from master.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 .git#test for 2.6.13-mm1. Doing (patch -R | grep FAILED) on 2.6.13-mm1 says: Right. 2.6.13/acpi-20050902-2.6.13.diff.gz is newers than 2.6.13-rc1's git-acpi.patch 2.6.13/acpi-20050815-2.6.13.diff.gz is a closer match -- though not exact. Peter, it might be illustrative if you have a moment if you can also test 2.6.13/acpi-20050815-2.6.13.diff.gz all by itself. If it fails, then I broke -mm1 with acpi-20050815-2.6.13.diff.gz, but fixed it by acpi-20050902-2.6.13.diff.gz. If it succeeds, then the issue lies in the relatively small delta between acpi-20050815-2.6.13.diff.gz 2.6.13-mm1's git-acpi.patch. thanks, -Len - 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/
2.6.13-mm1 login fails (RE: 2.6.13-mm1: hangs during boot ...)
As for the inability to log in, this bug may be relevant, given I also had that problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422 There are fixes in the pipeline for util-linux audit interaction in Fedora as well. I know because I reported those too ;) after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. The workaround by enabling audit support, but obviously a better fix is in the pipeline.. I'm surprised more people aren't discovering these 'interactions' due to having audit not turned on. Does everyone build audit into their kernels? This sure made my FC4 test boxes hard to use! CONFIG_AUDIT=y indeed did the trick. When will I be able to delete CONFIG_AUDIT from my kernel again? thanks -Len - 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.6.13-mm1: hangs during boot ...
On Sat, 2005-09-03 at 23:51 +1000, Peter Williams wrote: Are you seeing this Device not ready message appear over and over, or just the once? Just the once. OK, I finally have a theory about this. It's the everything goes via bios code. Previously there were several levels at which commands could exit the SCSI stack; now we make everything go via bios, so they all come out at the top. get_capabilities() in sr.c is sending a TEST_UNIT_READY which will get NOT_READY back. Previously this was completing before it got to scsi_io_completion(); now it doesn't. There must be quite a few cases like this. The best fix is probably to use and respect REQ_QUIET for internally generated commands. James - 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.6.13-mm1 login fails
From: Brown, Len [EMAIL PROTECTED] Date: Sat, 3 Sep 2005 12:58:15 -0400 CONFIG_AUDIT=y indeed did the trick. When will I be able to delete CONFIG_AUDIT from my kernel again? It's a regression we accidently added to the netlink socket family, we will fix it. But please use the workaround of enabling CONFIG_AUDIT until we fix it, thanks. - 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.6.13-mm1
Adrian Bunk [EMAIL PROTECTED] wrote: Hi Andrew, it seems you dropped schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's zero mentioning of this dropping in the changelog of 2.6.13-mm1. Can you explain why you did silently drop it? It spat rejects and when I looked at the putative removal date I just didn't believe it anyway. Send a rediffed one if you like, but October 2005 is unrealistic. - 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.6.13-mm1
On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote: Adrian Bunk [EMAIL PROTECTED] wrote: Hi Andrew, it seems you dropped schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's zero mentioning of this dropping in the changelog of 2.6.13-mm1. Can you explain why you did silently drop it? It spat rejects and when I looked at the putative removal date I just didn't believe it anyway. Send a rediffed one if you like, but October 2005 is unrealistic. That the date is no longer realistic is clear. What disappoints me is that you didn't mention in the changelog of 2.6.13-mm1 where I'd have noticed it. It semms I need my own bookkeeping of patches I sent that are in -mm to notice when they get lost. The only positive side effect of this is that I can use this to push you harder to forward some patches of me to Linus that stay unforwarded in -mm for several months... cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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.6.13-mm1
Adrian Bunk [EMAIL PROTECTED] wrote: On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote: Adrian Bunk [EMAIL PROTECTED] wrote: Hi Andrew, it seems you dropped schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's zero mentioning of this dropping in the changelog of 2.6.13-mm1. Can you explain why you did silently drop it? It spat rejects and when I looked at the putative removal date I just didn't believe it anyway. Send a rediffed one if you like, but October 2005 is unrealistic. That the date is no longer realistic is clear. What disappoints me is that you didn't mention in the changelog of 2.6.13-mm1 where I'd have noticed it. Sometimes I can't be bothered getting into email threads over relatively unimportant stuff. Usually it's related to the number of bugs we have. It semms I need my own bookkeeping of patches I sent that are in -mm to notice when they get lost. This is called quilt. The only positive side effect of this is that I can use this to push you harder to forward some patches of me to Linus that stay unforwarded in -mm for several months... A single release cycle is 2-3 months. I'll probably be dropping some of the patches which unexport symbols, btw. ANy ones which aren't really, really obvious. We have a process for this. - 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.6.13-mm1: hangs during boot ...
Brown, Len wrote: Please then try the latest ACPI patch here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches /release/2.6.13/acpi-20050902-2.6.13.diff.gz It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig that you can ignore. If this works, then we munged git-acpi.patch in 2.6.13-mm1 somehow. There were no problems with this patch applied. So it looks like the munge theory is correct. That diff is significantly different from the diff I plucked from master.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 .git#test for 2.6.13-mm1. Doing (patch -R | grep FAILED) on 2.6.13-mm1 says: Right. 2.6.13/acpi-20050902-2.6.13.diff.gz is newers than 2.6.13-rc1's git-acpi.patch 2.6.13/acpi-20050815-2.6.13.diff.gz is a closer match -- though not exact. Peter, it might be illustrative if you have a moment if you can also test 2.6.13/acpi-20050815-2.6.13.diff.gz all by itself. If it fails, It does. then I broke -mm1 with acpi-20050815-2.6.13.diff.gz, but fixed it by acpi-20050902-2.6.13.diff.gz. So you did. If it succeeds, then the issue lies in the relatively small delta between acpi-20050815-2.6.13.diff.gz 2.6.13-mm1's git-acpi.patch. thanks, -Len My pleasure Peter -- Peter Williams [EMAIL PROTECTED] Learning, n. The kind of ignorance distinguishing the studious. -- Ambrose Bierce - 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.6.13-mm1: hangs during boot ...
>Brown, Len wrote: [ 279.662960] [] wait_for_completion+0xa4/0x110 >> >> >> possibly a missing interrupt? >> >> >>>CONFIG_ACPI=y >> >> >> any difference if booted with "acpi=off" or "acpi=noirq"? > >Yes. In both cases, the system appears to boot normally but >I'm unable >to login or connect via ssh. Also there's a "device not >ready" message >after the scsi initialization which I don't normally see. >I've attached >the scsi initialization output. The PF_NETLINK error messages >after the >login prompt in this output are created whenever I try to log in or >connect via ssh. Please confirm that vanilla 2.6.13 has none of these symptoms. Please apply just the ACPI part of the 2.6.13-mm1 patch to see if these issues are caused by that or if they are caused by something else in the mm patch. http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/broken-out/git-acpi.patch thanks, -Len - 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.6.13-mm1: hangs during boot ...
Peter Williams <[EMAIL PROTECTED]> wrote: > > Brown, Len wrote: > >>>[ 279.662960] [] wait_for_completion+0xa4/0x110 > > > > > > possibly a missing interrupt? > > > > > >>CONFIG_ACPI=y > > > > > > any difference if booted with "acpi=off" or "acpi=noirq"? > > Yes. In both cases, the system appears to boot normally OK, we can pass this ball over to the ACPI team. > but I'm unable > to login or connect via ssh. Also there's a "device not ready" message > after the scsi initialization which I don't normally see. I've attached > the scsi initialization output. The PF_NETLINK error messages after the > login prompt in this output are created whenever I try to log in or > connect via ssh. Linus hit that too - it's an interaction between PAM and a modified netlink error code. Dave, where are we up to with the fix for that? - 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.6.13-mm1: hangs during boot ...
Brown, Len wrote: [ 279.662960] [] wait_for_completion+0xa4/0x110 possibly a missing interrupt? CONFIG_ACPI=y any difference if booted with "acpi=off" or "acpi=noirq"? Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a "device not ready" message after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce [8.345086] SCSI subsystem initialized [8.427503] sym0: <810a> rev 0x23 at pci :00:08.0 irq 16 [8.504636] sym0: No NVRAM, ID 7, Fast-10, SE, parity checking [8.588216] sym0: SCSI BUS has been reset. [8.642194] scsi0 : sym-2.2.1 [ 12.368622] Vendor: PIONEER Model: DVD-ROM DVD-303R Rev: 2.00 [ 12.450118] Type: CD-ROM ANSI SCSI revision:2[ 12.546506] target0:0:2: Beginning Domain Validation [ 12.613354] target0:0:2: asynchronous. [ 12.667699] target0:0:2: Domain Validation skipping write tests [ 12.747629] target0:0:2: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8) [ 12.837395] target0:0:2: Ending Domain Validation [ 13.256875] Vendor: SONY Model: CD-RW CRX140SRev: 1.0e [ 13.338323] Type: CD-ROM ANSI SCSI revision:4[ 13.434891] target0:0:4: Beginning Domain Validation [ 13.503101] target0:0:4: asynchronous. [ 13.602931] target0:0:4: Domain Validation skipping write tests [ 13.683605] target0:0:4: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8) [ 13.777934] target0:0:4: Ending Domain Validation [ 14.884703] Device not ready. [ 15.763312] kjournald starting. Commit interval 5 seconds [ 15.835612] EXT3-fs: mounted filesystem with ordered data mode. Fedora Core release 4 (Stentz) Kernel 2.6.13-mm1 on an i686 origma.pw.nest login: [ 101.886572] DEBUG: Failed to load PF_NETLINK protocol 9 [ 101.963572] DEBUG: Failed to load PF_NETLINK protocol 9
RE: 2.6.13-mm1: hangs during boot ...
> > [ 279.662960] [] wait_for_completion+0xa4/0x110 possibly a missing interrupt? > CONFIG_ACPI=y any difference if booted with "acpi=off" or "acpi=noirq"? - 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.6.13-mm1: hangs during boot ...
Peter Williams <[EMAIL PROTECTED]> wrote: > > Andrew Morton wrote: > > Peter Williams <[EMAIL PROTECTED]> wrote: > > > >>... at the the point indicated by the following output: > >> > >>[8.197224] Freeing unused kernel memory: 288k freed > >>[8.428217] SCSI subsystem initialized > >>[8.510376] sym0: <810a> rev 0x23 at pci :00:08.0 irq 11 > >>[8.587731] sym0: No NVRAM, ID 7, Fast-10, SE, parity checking > >>[8.671531] sym0: SCSI BUS has been reset. > >>[8.725530] scsi0 : sym-2.2.1 > >>[ 17.256480] 0:0:0:0: ABORT operation started. > >>[ 22.323534] 0:0:0:0: ABORT operation timed-out. > >>[ 22.384348] 0:0:0:0: DEVICE RESET operation started. > >>[ 27.458702] 0:0:0:0: DEVICE RESET operation timed-out. > >>[ 27.527544] 0:0:0:0: BUS RESET operation started. > >>[ 32.533775] 0:0:0:0: BUS RESET operation timed-out. > >>[ 32.599173] 0:0:0:0: HOST RESET operation started. > >>[ 32.669659] sym0: SCSI BUS has been reset. > >> > > > > > > Is there no response from sysrq-T? > > Now that I've tried it there is a response. I've attached the complete > output from the boot including the sysrq-T output in the hang.output > attachment to this e-mail. Thanks. > ... > [ 278.990398] Call Trace: > [ 279.024761] [] serio_thread+0xbf/0xf0 > [ 279.085573] [] kthread+0xa6/0xb0 > [ 279.140552] [] kernel_thread_helper+0x5/0xc > [ 279.208130] insmodD C171DCC0 0 227 1 232 > 70 )[ 279.309031] d7f33b04 d7f33ab8 d8836bb0 c171dcc0 1055 0fbf64f3 > d > [ 279.408678]e83b d7f33acc c01da354 d750e6ac d750e570 c130d160 > 0a9 > [ 279.518639]d7f32000 0a72aa15 0002 0246 c172de50 c172de50 > d7f > [ 279.628599] Call Trace: > [ 279.662960] [] wait_for_completion+0xa4/0x110 > [ 279.732934] [] blk_execute_rq+0x66/0xb0 > [ 279.796035] [] scsi_execute+0xb6/0xd0 [scsi_mod] > [ 279.869446] [] scsi_execute_req+0x7d/0xb0 [scsi_mod] > [ 279.947438] [] scsi_probe_lun+0xb6/0x1d0 [scsi_mod] > [ 280.024285] [] scsi_probe_and_add_lun+0xde/0x1e0 [scsi_mod] > [ 280.110295] [] scsi_scan_target+0xc9/0x140 [scsi_mod] > [ 280.189431] [] scsi_scan_channel+0x78/0x90 [scsi_mod] > [ 280.268569] [] scsi_scan_host_selected+0xc9/0x120 [scsi_mod] > [ 280.355722] [] scsi_scan_host+0x22/0x30 [scsi_mod] > [ 280.431425] [] sym2_probe+0xf5/0x120 [sym53c8xx] > [ 280.504835] [] pci_call_probe+0xd/0x10 > [ 280.566791] [] __pci_device_probe+0x49/0x60 > [ 280.634369] [] pci_device_probe+0x29/0x50 > [ 280.699657] [] driver_probe_device+0x3e/0xc0 > [ 280.768486] [] __driver_attach+0x5f/0x70 > [ 280.832628] [] bus_for_each_dev+0x43/0x70 > [ 280.897916] [] driver_attach+0x19/0x20 > [ 280.959770] [] bus_add_driver+0x7b/0xd0 > [ 281.022767] [] driver_register+0x42/0x50 > [ 281.086910] [] pci_register_driver+0x70/0x90 > [ 281.155635] [] sym2_init+0x2b/0x45 [sym53c8xx] > [ 281.226752] [] sys_init_module+0xec/0x230 > [ 281.292042] [] syscall_call+0x7/0xb > [ 281.350458] scsi_eh_0 D 0 232 1 > 227 )[ 281.451357] d7a51ea0 d7a51e64 1e62bb57 d7a5 1e62c494 > d > [ 281.551005]0106 d79b0ab0 c130d160 d79b0bec d79b0ab0 c130d160 > 9de > [ 281.660963]d7a5 9de05c44 0007 d7a5 d7a51ef4 d7a51ef0 > d7a > [ 281.770923] Call Trace: > [ 281.805288] [] wait_for_completion+0xa4/0x110 > [ 281.875159] [] sym_eh_handler+0x240/0x290 [sym53c8xx] > [ 281.954293] [] sym53c8xx_eh_host_reset_handler+0x2d/0x50 > [sym53c8][ 282.050611] [] scsi_try_host_reset+0x2b/0xa0 [scsi_mod] > [ 282.132041] [] scsi_eh_host_reset+0x1c/0xa0 [scsi_mod] > [ 282.212324] [] scsi_eh_ready_devs+0x57/0x70 [scsi_mod] > [ 282.292604] [] scsi_unjam_host+0x9f/0xc0 [scsi_mod] > [ 282.369451] [] scsi_error_handler+0xb9/0xe0 [scsi_mod] > [ 282.449734] [] kernel_thread_helper+0x5/0xc > scsi went ga-ga during insertion of the sym2 driver. Usual culprits cc'ed ;) - 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.6.13-mm1: hangs during boot ...
Andrew Morton wrote: Peter Williams <[EMAIL PROTECTED]> wrote: ... at the the point indicated by the following output: [8.197224] Freeing unused kernel memory: 288k freed [8.428217] SCSI subsystem initialized [8.510376] sym0: <810a> rev 0x23 at pci :00:08.0 irq 11 [8.587731] sym0: No NVRAM, ID 7, Fast-10, SE, parity checking [8.671531] sym0: SCSI BUS has been reset. [8.725530] scsi0 : sym-2.2.1 [ 17.256480] 0:0:0:0: ABORT operation started. [ 22.323534] 0:0:0:0: ABORT operation timed-out. [ 22.384348] 0:0:0:0: DEVICE RESET operation started. [ 27.458702] 0:0:0:0: DEVICE RESET operation timed-out. [ 27.527544] 0:0:0:0: BUS RESET operation started. [ 32.533775] 0:0:0:0: BUS RESET operation timed-out. [ 32.599173] 0:0:0:0: HOST RESET operation started. [ 32.669659] sym0: SCSI BUS has been reset. Is there no response from sysrq-T? Now that I've tried it there is a response. I've attached the complete output from the boot including the sysrq-T output in the hang.output attachment to this e-mail. Maybe adding initcall_debug to the boot command line will show extra info? The .config would be useful, thanks. Attached as origma.config. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce root (hd1,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.6.13-mm1 ro root=/dev/hdb2 psmouse.proto=imps console=ttyS0, 9600,n8 console=tty0 elevator=cfq initcall_debug [Linux-bzImage, setup=0x1c00, size=0x160a00] initrd /initrd-2.6.13-mm1.img [Linux-initrd @ 0x17ed, 0x10f799 bytes] [17179569.184000] Linux version 2.6.13-mm1 ([EMAIL PROTECTED]) (gcc version5[17179569.184000] BIOS-provided physical RAM map: [17179569.184000] BIOS-e820: - 0009fc00 (usable) [17179569.184000] BIOS-e820: 0009fc00 - 000a (reserved) [17179569.184000] BIOS-e820: 000f - 0010 (reserved) [17179569.184000] BIOS-e820: 0010 - 17ff (usable) [17179569.184000] BIOS-e820: 17ff - 17ff3000 (ACPI NVS) [17179569.184000] BIOS-e820: 17ff3000 - 1800 (ACPI data) [17179569.184000] BIOS-e820: fec0 - fec01000 (reserved) [17179569.184000] BIOS-e820: fee0 - fee01000 (reserved) [17179569.184000] BIOS-e820: - 0001 (reserved) [17179569.184000] 0MB HIGHMEM available. [17179569.184000] 383MB LOWMEM available. [17179569.184000] found SMP MP-table at 000f5b50 [17179569.184000] DMI 2.1 present. [17179569.184000] Using APIC driver default [17179569.184000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [17179569.184000] Processor #0 6:6 APIC version 17 [17179569.184000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [17179569.184000] Processor #1 6:6 APIC version 17 [17179569.184000] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [17179569.184000] IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23[17179569.184000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge) [17179569.184000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl) [17179569.184000] Enabling APIC mode: Flat. Using 1 I/O APICs [17179569.184000] Using ACPI (MADT) for SMP configuration information [17179569.184000] Allocating PCI resources starting at 1800 (gap: 1800:)[17179569.184000] Built 1 zonelists [17179569.184000] Initializing CPU#0 [17179569.184000] Kernel command line: ro root=/dev/hdb2 psmouse.proto=imps cog[17179569.184000] PID hash table entries: 2048 (order: 11, 32768 bytes) [0.00] Detected 498.852 MHz processor. [ 138.776886] Using tsc for high-res timesource [ 138.778122] Console: colour VGA+ 80x25 [ 141.445574] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 141.540255] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 141.691186] Memory: 383616k/393152k available (1890k kernel code, 8920k rese)[ 141.828739] Checking if this processor honours the WP bit even in supervisor.[ 142.013460] Calibrating delay using timer specific routine.. 999.15 BogoMIPS)[ 142.122666] Mount-cache hash table entries: 512 [ 142.182861] CPU: L1 I cache: 16K, L1 D cache: 16K [ 142.244915] CPU: L2 cache: 128K [ 142.286285] Intel machine check architecture supported. [ 142.355089] Intel machine check reporting enabled on CPU#0. [ 142.428541] mtrr: v2.0 (20020519) [ 142.472137] Enabling fast FPU save and restore... done. [ 142.541059] Checking 'hlt' instruction... OK. [ 142.623314] ACPI-0284: *** Error: Region SystemMemory(0) has no handler [ 142.715171] ACPI-0115: *** Error: acpi_load_tables: Could not load namesT[ 142.828766] ACPI-0123: *** Error: acpi_load_tables: Could not load tableT[ 142.938929] ACPI: Unable to load the System Description Tables [ 143.015900] CPU0: Intel Celeron
Re: 2.6.13-mm1
On Fri, 2 Sep 2005 14:45:52 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
>"J.A. Magallon" <[EMAIL PROTECTED]> wrote:
>>
[...]
>> Still the same result, system bocks starting udev...
>>
>
>OK, thanks. Nothing from sysrq-t? Does the below help?
>
>---
>devel/fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix
>2005-09-02 04:01:40.0 -0700
>+++ devel-akpm/fs/sysfs/file.c 2005-09-02 04:05:02.0 -0700
>@@ -202,13 +202,14 @@ fill_write_buffer(struct sysfs_buffer *
> *passing the buffer that we acquired in fill_write_buffer().
> */
>
>-static int
>-flush_write_buffer(struct dentry * dentry, struct sysfs_buffer * buffer,
>size_t count)
>+static int flush_write_buffer(struct dentry *dentry,
>+ struct sysfs_buffer *buffer, size_t count_in)
> {
> struct attribute * attr = to_attr(dentry);
> struct kobject * kobj = to_kobj(dentry->d_parent);
> struct sysfs_ops * ops = buffer->ops;
> char *x;
>+ size_t count = count_in;
>
> /* locate trailing white space */
> while ((count > 0) && isspace(buffer->page[count - 1]))
>@@ -224,7 +225,8 @@ flush_write_buffer(struct dentry * dentr
> /* terminate the string */
> x[count] = '\0';
>
>- return ops->store(kobj, attr, x, count);
>+ ops->store(kobj, attr, x, count);
>+ return count_in;
> }
>
>
Hi Andrew,
Patch above fixes problem with sysfs writes to adm9240 driver
locking up console in last three -mm kernels.
Grant.
-
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.6.13-mm1
On 09.02, Andrew Morton wrote:
> "J.A. Magallon" <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 09.02, Andrew Morton wrote:
> > > "J.A. Magallon" <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> > > > >
> > > > > - Included Alan's big tty layer buffering rewrite. This breaks the
> > > > > build on
> > > > > lots of more obscure character device drivers. Patches welcome
> > > > > (please cc
> > > > > Alan).
> > > > >
> > > >
> > > > I have problems with udev and latest -mm.
> > > > 2.6.13 boots fine, but 2.6.13-mm1 blocks when starting udev.
> > > > System is Mandriva Cooker. As cooker, things are changing fast
> > > > (initscripts,
> > > > udev, etc), but the fact is that with the same setup, plain .13 boots
> > > > and -mm1 blocks. Udev is 068 version.
> > > >
> > > > Any idea about what can be the reason ?
> > > >
> > >
> > > There's some suspect locking in the /proc/devices seq_file conversion
> > > code.
> > >
> > > Could you revert convert-proc-devices-to-use-seq_file-interface-fix.patch
> > > then convert-proc-devices-to-use-seq_file-interface.patch?
> > >
> >
> > Still the same result, system bocks starting udev...
> >
>
> OK, thanks. Nothing from sysrq-t? Does the below help?
>
> ---
> devel/fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix
>2005-09-02 04:01:40.0 -0700
> +++ devel-akpm/fs/sysfs/file.c2005-09-02 04:05:02.0 -0700
> @@ -202,13 +202,14 @@ fill_write_buffer(struct sysfs_buffer *
> * passing the buffer that we acquired in fill_write_buffer().
> */
>
> -static int
> -flush_write_buffer(struct dentry * dentry, struct sysfs_buffer * buffer,
> size_t count)
> +static int flush_write_buffer(struct dentry *dentry,
> + struct sysfs_buffer *buffer, size_t count_in)
> {
> struct attribute * attr = to_attr(dentry);
> struct kobject * kobj = to_kobj(dentry->d_parent);
> struct sysfs_ops * ops = buffer->ops;
> char *x;
> + size_t count = count_in;
>
> /* locate trailing white space */
> while ((count > 0) && isspace(buffer->page[count - 1]))
> @@ -224,7 +225,8 @@ flush_write_buffer(struct dentry * dentr
> /* terminate the string */
> x[count] = '\0';
>
> - return ops->store(kobj, attr, x, count);
> + ops->store(kobj, attr, x, count);
> + return count_in;
> }
>
Bingo !.
That did the trink. Booting fine again.
I meant, just with this, without reverting the other 2 patches.
Thanks !
--
J.A. Magallon \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.13-jam2 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0))
-
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.6.13-mm1
"J.A. Magallon" <[EMAIL PROTECTED]> wrote:
>
>
> On 09.02, Andrew Morton wrote:
> > "J.A. Magallon" <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> > > >
> > > > - Included Alan's big tty layer buffering rewrite. This breaks the
> > > > build on
> > > > lots of more obscure character device drivers. Patches welcome
> > > > (please cc
> > > > Alan).
> > > >
> > >
> > > I have problems with udev and latest -mm.
> > > 2.6.13 boots fine, but 2.6.13-mm1 blocks when starting udev.
> > > System is Mandriva Cooker. As cooker, things are changing fast
> > > (initscripts,
> > > udev, etc), but the fact is that with the same setup, plain .13 boots
> > > and -mm1 blocks. Udev is 068 version.
> > >
> > > Any idea about what can be the reason ?
> > >
> >
> > There's some suspect locking in the /proc/devices seq_file conversion code.
> >
> > Could you revert convert-proc-devices-to-use-seq_file-interface-fix.patch
> > then convert-proc-devices-to-use-seq_file-interface.patch?
> >
>
> Still the same result, system bocks starting udev...
>
OK, thanks. Nothing from sysrq-t? Does the below help?
---
devel/fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix
2005-09-02 04:01:40.0 -0700
+++ devel-akpm/fs/sysfs/file.c 2005-09-02 04:05:02.0 -0700
@@ -202,13 +202,14 @@ fill_write_buffer(struct sysfs_buffer *
* passing the buffer that we acquired in fill_write_buffer().
*/
-static int
-flush_write_buffer(struct dentry * dentry, struct sysfs_buffer * buffer,
size_t count)
+static int flush_write_buffer(struct dentry *dentry,
+ struct sysfs_buffer *buffer, size_t count_in)
{
struct attribute * attr = to_attr(dentry);
struct kobject * kobj = to_kobj(dentry->d_parent);
struct sysfs_ops * ops = buffer->ops;
char *x;
+ size_t count = count_in;
/* locate trailing white space */
while ((count > 0) && isspace(buffer->page[count - 1]))
@@ -224,7 +225,8 @@ flush_write_buffer(struct dentry * dentr
/* terminate the string */
x[count] = '\0';
- return ops->store(kobj, attr, x, count);
+ ops->store(kobj, attr, x, count);
+ return count_in;
}
_
-
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.6.13-mm1
Benjamin LaHaise <[EMAIL PROTECTED]> wrote: > > On Thu, Sep 01, 2005 at 03:55:42AM -0700, Andrew Morton wrote: > > Dropped (I have it in a new AIO patch series but I took yet another look at > > all the AIO stuff and felt queasy) > > What's the nature of the queasiness? Is it something that can be addressed > by rewriting the patches, or just general worries about adding another > feature? The status quo is not acceptable. > Cons: - Additional arguments to various fastpath functions - Additional code size - Additional code complexity - Significantly degrades collective understanding of how the VFS works. Pros: - Unclear. - 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.6.13-mm1: hangs during boot ...
Peter Williams <[EMAIL PROTECTED]> wrote: > > ... at the the point indicated by the following output: > > [8.197224] Freeing unused kernel memory: 288k freed > [8.428217] SCSI subsystem initialized > [8.510376] sym0: <810a> rev 0x23 at pci :00:08.0 irq 11 > [8.587731] sym0: No NVRAM, ID 7, Fast-10, SE, parity checking > [8.671531] sym0: SCSI BUS has been reset. > [8.725530] scsi0 : sym-2.2.1 > [ 17.256480] 0:0:0:0: ABORT operation started. > [ 22.323534] 0:0:0:0: ABORT operation timed-out. > [ 22.384348] 0:0:0:0: DEVICE RESET operation started. > [ 27.458702] 0:0:0:0: DEVICE RESET operation timed-out. > [ 27.527544] 0:0:0:0: BUS RESET operation started. > [ 32.533775] 0:0:0:0: BUS RESET operation timed-out. > [ 32.599173] 0:0:0:0: HOST RESET operation started. > [ 32.669659] sym0: SCSI BUS has been reset. > Is there no response from sysrq-T? Maybe adding initcall_debug to the boot command line will show extra info? The .config would be useful, thanks. - 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.6.13-mm1
On Thu, Sep 01, 2005 at 03:55:42AM -0700, Andrew Morton wrote: > Dropped (I have it in a new AIO patch series but I took yet another look at > all the AIO stuff and felt queasy) What's the nature of the queasiness? Is it something that can be addressed by rewriting the patches, or just general worries about adding another feature? The status quo is not acceptable. -ben - 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.6.13-mm1
On 09.02, Andrew Morton wrote: > "J.A. Magallon" <[EMAIL PROTECTED]> wrote: > > > > > > On 1/09/2005 10:58 a.m., Andrew Morton wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/ > > > > > > - Included Alan's big tty layer buffering rewrite. This breaks the build > > > on > > > lots of more obscure character device drivers. Patches welcome (please > > > cc > > > Alan). > > > > > > > I have problems with udev and latest -mm. > > 2.6.13 boots fine, but 2.6.13-mm1 blocks when starting udev. > > System is Mandriva Cooker. As cooker, things are changing fast (initscripts, > > udev, etc), but the fact is that with the same setup, plain .13 boots > > and -mm1 blocks. Udev is 068 version. > > > > Any idea about what can be the reason ? > > > > There's some suspect locking in the /proc/devices seq_file conversion code. > > Could you revert convert-proc-devices-to-use-seq_file-interface-fix.patch > then convert-proc-devices-to-use-seq_file-interface.patch? > Still the same result, system bocks starting udev... -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandriva Linux release 2006.0 (Cooker) for i586 Linux 2.6.13 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0)) - 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-usb-devel] Re: 2.6.13-mm1
On Thu, 1 Sep 2005, Andrew Morton wrote: > Reuben Farrelly <[EMAIL PROTECTED]> wrote: > > I'm also observing some USB messages logged: > > > > Sep 2 13:26:22 tornado kernel: usb 5-1: new full speed USB device using > > uhci_hcd and address 13 > > Sep 2 13:26:22 tornado kernel: drivers/usb/class/usblp.c: usblp0: USB > > Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x6204 > > Sep 2 13:26:23 tornado kernel: hub 5-0:1.0: port 1 disabled by hub (EMI?), > > re-enabling... This message means pretty much what it says: noise or something else caused the connection to be disabled. In theory this could be caused by a problem with the host controller, the cable, or the printer. Does this happen consistently with 2.6.13-mm1? Did it happen with 2.6.12? > > Sep 2 13:26:23 tornado kernel: usb 5-1: USB disconnect, address 13 > > Sep 2 13:26:23 tornado kernel: drivers/usb/class/usblp.c: usblp0: removed > > Sep 2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using > > uhci_hcd and address 14 > > Sep 2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error > > -71 > > Sep 2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error > > -71 > > Sep 2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using > > uhci_hcd and address 15 > > Sep 2 13:26:23 tornado kernel: usb 5-1: device descriptor read/all, error > > -71 > > Sep 2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using > > uhci_hcd and address 16 > > Sep 2 13:26:23 tornado kernel: usb 5-1: can't set config #1, error -71 > > Sep 2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using > > uhci_hcd and address 17 > > Sep 2 13:26:24 tornado kernel: usb 5-1: unable to read config index 0 > > descriptor/start > > Sep 2 13:26:24 tornado kernel: usb 5-1: can't read configurations, error > > -71 If it's not already in 2.6.13-mm1, this patch may help with the reinitialization: http://marc.theaimsgroup.com/?l=linux-usb-devel=112551468126219=2 Alan Stern - 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.6.13-mm1
On Fri, 2 Sep 2005, Alexander Nyberg wrote:
> On Thu, Sep 01, 2005 at 03:55:42AM -0700 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> >
>
> i386-boottime-for_each_cpu-broken.patch
> i386-boottime-for_each_cpu-broken-fix.patch
>
> The SMP version of __alloc_percpu checks the cpu_possible_map
> before allocating memory for a certain cpu. With the above patches
> the BSP cpuid is never set in cpu_possible_map which breaks CONFIG_SMP
> on uniprocessor machines (as soon as someone tries to dereference
> something allocated via __alloc_percpu, which in fact is never allocated
> since the cpu is not set in cpu_possible_map).
Yes indeed, if there is no mptable or madt we would have missed setting
it.
> The below fixes this, I'm not entirely sure about the voyager
> part, should the cpu_possible_map really be CPU_MASK_ALL to begin
> with there, Zwane?
I wanted to avoid breaking it wholesale and since i don't entirely
understand the voyager SMP boot sequence, i opted for the safe method.
cpu_possible_map is fine because it's supposed to cover all possible
processors, upto NR_CPUS.
> Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>
Thanks Alex,
Acked-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
> Index: mm/arch/i386/kernel/smpboot.c
> ===
> --- mm.orig/arch/i386/kernel/smpboot.c2005-09-02 15:28:20.0
> +0200
> +++ mm/arch/i386/kernel/smpboot.c 2005-09-02 16:16:46.0 +0200
> @@ -1265,6 +1265,7 @@
> cpu_set(smp_processor_id(), cpu_online_map);
> cpu_set(smp_processor_id(), cpu_callout_map);
> cpu_set(smp_processor_id(), cpu_present_map);
> + cpu_set(smp_processor_id(), cpu_possible_map);
> per_cpu(cpu_state, smp_processor_id()) = CPU_ONLINE;
> }
>
> Index: mm/arch/i386/mach-voyager/voyager_smp.c
> ===
> --- mm.orig/arch/i386/mach-voyager/voyager_smp.c 2005-09-02
> 15:28:20.0 +0200
> +++ mm/arch/i386/mach-voyager/voyager_smp.c 2005-09-02 16:17:29.0
> +0200
> @@ -1910,6 +1910,7 @@
> {
> cpu_set(smp_processor_id(), cpu_online_map);
> cpu_set(smp_processor_id(), cpu_callout_map);
> + cpu_set(smp_processor_id(), cpu_possible_map);
> }
>
> int __devinit
> -
> 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/
>
-
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.6.13-mm1
On Thu, Sep 01, 2005 at 03:55:42AM -0700 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
>
i386-boottime-for_each_cpu-broken.patch
i386-boottime-for_each_cpu-broken-fix.patch
The SMP version of __alloc_percpu checks the cpu_possible_map
before allocating memory for a certain cpu. With the above patches
the BSP cpuid is never set in cpu_possible_map which breaks CONFIG_SMP
on uniprocessor machines (as soon as someone tries to dereference
something allocated via __alloc_percpu, which in fact is never allocated
since the cpu is not set in cpu_possible_map).
The below fixes this, I'm not entirely sure about the voyager
part, should the cpu_possible_map really be CPU_MASK_ALL to begin
with there, Zwane?
Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>
Index: mm/arch/i386/kernel/smpboot.c
===
--- mm.orig/arch/i386/kernel/smpboot.c 2005-09-02 15:28:20.0 +0200
+++ mm/arch/i386/kernel/smpboot.c 2005-09-02 16:16:46.0 +0200
@@ -1265,6 +1265,7 @@
cpu_set(smp_processor_id(), cpu_online_map);
cpu_set(smp_processor_id(), cpu_callout_map);
cpu_set(smp_processor_id(), cpu_present_map);
+ cpu_set(smp_processor_id(), cpu_possible_map);
per_cpu(cpu_state, smp_processor_id()) = CPU_ONLINE;
}
Index: mm/arch/i386/mach-voyager/voyager_smp.c
===
--- mm.orig/arch/i386/mach-voyager/voyager_smp.c2005-09-02
15:28:20.0 +0200
+++ mm/arch/i386/mach-voyager/voyager_smp.c 2005-09-02 16:17:29.0
+0200
@@ -1910,6 +1910,7 @@
{
cpu_set(smp_processor_id(), cpu_online_map);
cpu_set(smp_processor_id(), cpu_callout_map);
+ cpu_set(smp_processor_id(), cpu_possible_map);
}
int __devinit
-
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.6.13-mm1: swsusp problem (was: PCMCIA problem)
On Friday, 2 of September 2005 13:45, Rafael J. Wysocki wrote: > On Friday, 2 of September 2005 13:09, Andrew Morton wrote: > > Pavel Machek <[EMAIL PROTECTED]> wrote: > > > > > > > One more piece of information. This is the one that loops: > > > > > > > > echo 30 > /sys/class/firmware/timeout > > > > > > Try echo -n ... > > > > Or revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch. > > Obviously if you write 30\n and the write returns 2 then the shell will > > then try to write the \n. That returns zero and the shell tries again, ad > > infinitum. > > > > Rant. It took me two full days to weed out and fix all the crap people > > sent me to get -mm1 into a state where it vaguely compiled and booted. And > > it's untested nonsense like this which wrecks the whole effort for many > > testers. > > > > I suppose this is as good as anything > > Thanks for the fix. :-) > > Now, (using the fact that Pavel already is in the CC list ;-)) there's another > issue I have with swsusp, which is broken in a funny way. Namely, after > resuming from disk the box immediately goes into standby from which it > can be woken up by pressing the power button, but then it oopses, > goes into standby (or something similar) again, and hangs solid (unfortunately > I can't get the traces right now). Sorry for the noise. This problem has been fixed by the same patch (ie suspend is initiated by writing a string to a file on sysfs etc.). Greetings, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.6.13-mm1: misc mwave issues
On Gwe, 2005-09-02 at 01:25 +0200, Adrian Bunk wrote: > The MWAVE also got a comment > # PLEASE DO NOT DO THIS - move this driver to drivers/serial Mwave is an interested toy - its mostly an enabled for the hardware and the services provided are not just serial but also audio etc - 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.6.13-mm1: swsusp problem (was: PCMCIA problem)
On Friday, 2 of September 2005 13:09, Andrew Morton wrote: > Pavel Machek <[EMAIL PROTECTED]> wrote: > > > > > One more piece of information. This is the one that loops: > > > > > > echo 30 > /sys/class/firmware/timeout > > > > Try echo -n ... > > Or revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch. > Obviously if you write 30\n and the write returns 2 then the shell will > then try to write the \n. That returns zero and the shell tries again, ad > infinitum. > > Rant. It took me two full days to weed out and fix all the crap people > sent me to get -mm1 into a state where it vaguely compiled and booted. And > it's untested nonsense like this which wrecks the whole effort for many > testers. > > I suppose this is as good as anything Thanks for the fix. :-) Now, (using the fact that Pavel already is in the CC list ;-)) there's another issue I have with swsusp, which is broken in a funny way. Namely, after resuming from disk the box immediately goes into standby from which it can be woken up by pressing the power button, but then it oopses, goes into standby (or something similar) again, and hangs solid (unfortunately I can't get the traces right now). Greetings, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.6.13-mm1: PCMCIA problem
Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > One more piece of information. This is the one that loops:
> >
> > echo 30 > /sys/class/firmware/timeout
>
> Try echo -n ...
Or revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch.
Obviously if you write 30\n and the write returns 2 then the shell will
then try to write the \n. That returns zero and the shell tries again, ad
infinitum.
Rant. It took me two full days to weed out and fix all the crap people
sent me to get -mm1 into a state where it vaguely compiled and booted. And
it's untested nonsense like this which wrecks the whole effort for many
testers.
I suppose this is as good as anything
From: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
fs/sysfs/file.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff -puN
fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix
fs/sysfs/file.c
---
devel/fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix
2005-09-02 04:01:40.0 -0700
+++ devel-akpm/fs/sysfs/file.c 2005-09-02 04:05:02.0 -0700
@@ -202,13 +202,14 @@ fill_write_buffer(struct sysfs_buffer *
* passing the buffer that we acquired in fill_write_buffer().
*/
-static int
-flush_write_buffer(struct dentry * dentry, struct sysfs_buffer * buffer,
size_t count)
+static int flush_write_buffer(struct dentry *dentry,
+ struct sysfs_buffer *buffer, size_t count_in)
{
struct attribute * attr = to_attr(dentry);
struct kobject * kobj = to_kobj(dentry->d_parent);
struct sysfs_ops * ops = buffer->ops;
char *x;
+ size_t count = count_in;
/* locate trailing white space */
while ((count > 0) && isspace(buffer->page[count - 1]))
@@ -224,7 +225,8 @@ flush_write_buffer(struct dentry * dentr
/* terminate the string */
x[count] = '\0';
- return ops->store(kobj, attr, x, count);
+ ops->store(kobj, attr, x, count);
+ return count_in;
}
_
-
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.6.13-mm1: PCMCIA problem
On Friday, 2 of September 2005 12:43, Pavel Machek wrote: > Hi! > > > > > > On Thursday, 1 of September 2005 12:55, Andrew Morton wrote: > > > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/ > > > > > > > > > > I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D. Apparently, > > > > > the following > > > > > command: > > > > > > > > > > sh -c modprobe --ignore-install firmware_class; echo 30 > > > > > > /sys/class/firmware/timeout > > > > > > > > > > loops forever with almost 100% of the time spent in the kernel. > > > > > > > > > > AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are > > > > > not. > > > > > > > > OK. There are no notable firmware changes in there. While it's stuck > > > > could you generate a kernel profile?I do: > > > > > > > > readprofile -r > > > > sleep 5 > > > > readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 > > > > ]--snip--[ > > > > One more piece of information. This is the one that loops: > > > > echo 30 > /sys/class/firmware/timeout > > Try echo -n ... Well that helps but it means the SuSE's scripts have to be changed to work with 2.6.13-mm1. Specifically "/etc/modprobe.d/firmware". Is that intentional or not? Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.6.13-mm1: PCMCIA problem
Hi! > > > > On Thursday, 1 of September 2005 12:55, Andrew Morton wrote: > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/ > > > > > > > > I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D. Apparently, the > > > > following > > > > command: > > > > > > > > sh -c modprobe --ignore-install firmware_class; echo 30 > > > > > /sys/class/firmware/timeout > > > > > > > > loops forever with almost 100% of the time spent in the kernel. > > > > > > > > AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are > > > > not. > > > > > > OK. There are no notable firmware changes in there. While it's stuck > > > could you generate a kernel profile?I do: > > > > > > readprofile -r > > > sleep 5 > > > readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 > > ]--snip--[ > > One more piece of information. This is the one that loops: > > echo 30 > /sys/class/firmware/timeout Try echo -n ... -- if you have sharp zaurus hardware you don't need... you know my address - 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.6.13-mm1: PCMCIA problem
On Friday, 2 of September 2005 10:30, Rafael J. Wysocki wrote: > On Thursday, 1 of September 2005 23:28, Andrew Morton wrote: > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > > > On Thursday, 1 of September 2005 12:55, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/ > > > > > > I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D. Apparently, the > > > following > > > command: > > > > > > sh -c modprobe --ignore-install firmware_class; echo 30 > > > > /sys/class/firmware/timeout > > > > > > loops forever with almost 100% of the time spent in the kernel. > > > > > > AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are not. > > > > OK. There are no notable firmware changes in there. While it's stuck > > could you generate a kernel profile?I do: > > > > readprofile -r > > sleep 5 > > readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 ]--snip--[ One more piece of information. This is the one that loops: echo 30 > /sys/class/firmware/timeout and the related profile is: 16 *unknown* 8010eb38 sysret_check 1 0.0120 80240b40 clear_page1 0.0175 80356397 bad_gs1 0.0001 80240cc0 copy_user_generic 2 0.0067 8010eb33 ret_from_sys_call 6 1.2000 80221870 dummy_file_permission 7 0.4375 80240c90 copy_from_user9 0.1875 8023f5e0 simple_strtol11 0.2292 8023f500 simple_strtoul 17 0.0759 802ac800 class_attr_store 18 0.3750 801bfc40 sysfs_write_file 61 0.1658 8017ead0 sys_write78 0.5417 8017df70 rw_verify_area 143 1.1172 80240dea copy_user_generic_c 144 3.7895 8010eab0 system_call 163 1.2443 8017f1d0 fget_light 184 0.7667 8017e890 vfs_write 209 0.5024 total 1055 0.0004 Greetings, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.6.13-mm1: PCMCIA problem
On Thursday, 1 of September 2005 23:28, Andrew Morton wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > On Thursday, 1 of September 2005 12:55, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/ > > > > I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D. Apparently, the > > following > > command: > > > > sh -c modprobe --ignore-install firmware_class; echo 30 > > > /sys/class/firmware/timeout > > > > loops forever with almost 100% of the time spent in the kernel. > > > > AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are not. > > OK. There are no notable firmware changes in there. While it's stuck > could you generate a kernel profile?I do: > > readprofile -r > sleep 5 > readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 OK I ran "rcpcmcia start" in one vt and the above in another. The result was: 20 *unknown* 802417f0 __memset 1 0.0052 80242850 _raw_spin_lock1 0.0031 8026a44c acpi_ns_get_next_node 1 0.0118 802ed040 sock_kfree_s 1 0.0156 8010eb38 sysret_check 2 0.0241 8010eb33 ret_from_sys_call 4 0.8000 80240cc0 copy_user_generic 5 0.0168 80221870 dummy_file_permission 7 0.4375 8023f5e0 simple_strtol14 0.2917 80240c90 copy_from_user 15 0.3125 802ac800 class_attr_store 17 0.3542 8017df70 rw_verify_area 22 0.1719 8023f500 simple_strtoul 24 0.1071 8017ead0 sys_write41 0.2847 80240dea copy_user_generic_c 82 2.1579 8017f1d0 fget_light 108 0.4500 8010eab0 system_call 189 1.4427 8017e890 vfs_write 220 0.5288 801bfc40 sysfs_write_file308 0.8370 total 1062 0.0004 After I had stopped the (looping) "rcpcmcia start", I got: 1243 *unknown* 80240dea copy_user_generic_c 1 0.0263 802417f0 __memset 1 0.0052 total 2 0. Greetings, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.6.13-mm1: PCMCIA problem
On Thursday, 1 of September 2005 23:28, Andrew Morton wrote: Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Thursday, 1 of September 2005 12:55, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/ I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D. Apparently, the following command: sh -c modprobe --ignore-install firmware_class; echo 30 /sys/class/firmware/timeout loops forever with almost 100% of the time spent in the kernel. AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are not. OK. There are no notable firmware changes in there. While it's stuck could you generate a kernel profile?I do: readprofile -r sleep 5 readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 OK I ran rcpcmcia start in one vt and the above in another. The result was: 20 *unknown* 802417f0 __memset 1 0.0052 80242850 _raw_spin_lock1 0.0031 8026a44c acpi_ns_get_next_node 1 0.0118 802ed040 sock_kfree_s 1 0.0156 8010eb38 sysret_check 2 0.0241 8010eb33 ret_from_sys_call 4 0.8000 80240cc0 copy_user_generic 5 0.0168 80221870 dummy_file_permission 7 0.4375 8023f5e0 simple_strtol14 0.2917 80240c90 copy_from_user 15 0.3125 802ac800 class_attr_store 17 0.3542 8017df70 rw_verify_area 22 0.1719 8023f500 simple_strtoul 24 0.1071 8017ead0 sys_write41 0.2847 80240dea copy_user_generic_c 82 2.1579 8017f1d0 fget_light 108 0.4500 8010eab0 system_call 189 1.4427 8017e890 vfs_write 220 0.5288 801bfc40 sysfs_write_file308 0.8370 total 1062 0.0004 After I had stopped the (looping) rcpcmcia start, I got: 1243 *unknown* 80240dea copy_user_generic_c 1 0.0263 802417f0 __memset 1 0.0052 total 2 0. Greetings, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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.6.13-mm1: PCMCIA problem
On Friday, 2 of September 2005 10:30, Rafael J. Wysocki wrote: On Thursday, 1 of September 2005 23:28, Andrew Morton wrote: Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Thursday, 1 of September 2005 12:55, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/ I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D. Apparently, the following command: sh -c modprobe --ignore-install firmware_class; echo 30 /sys/class/firmware/timeout loops forever with almost 100% of the time spent in the kernel. AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are not. OK. There are no notable firmware changes in there. While it's stuck could you generate a kernel profile?I do: readprofile -r sleep 5 readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 ]--snip--[ One more piece of information. This is the one that loops: echo 30 /sys/class/firmware/timeout and the related profile is: 16 *unknown* 8010eb38 sysret_check 1 0.0120 80240b40 clear_page1 0.0175 80356397 bad_gs1 0.0001 80240cc0 copy_user_generic 2 0.0067 8010eb33 ret_from_sys_call 6 1.2000 80221870 dummy_file_permission 7 0.4375 80240c90 copy_from_user9 0.1875 8023f5e0 simple_strtol11 0.2292 8023f500 simple_strtoul 17 0.0759 802ac800 class_attr_store 18 0.3750 801bfc40 sysfs_write_file 61 0.1658 8017ead0 sys_write78 0.5417 8017df70 rw_verify_area 143 1.1172 80240dea copy_user_generic_c 144 3.7895 8010eab0 system_call 163 1.2443 8017f1d0 fget_light 184 0.7667 8017e890 vfs_write 209 0.5024 total 1055 0.0004 Greetings, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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/
