Re: [bug] uml doesn't boot under 2.6.25-rc1 host (was Re: 2.6.24-mm1 bugs)
Thanks for the pointers, guys. It took a while for me to figure out what got wrong to foul up UML, but the bug and fix are trivial (posting now). Some of the testing I thought had got done clearly wasn't done, since PTRACE_SETREGS was 100% busticated for 32-bit processes calling ptrace on x86_64 kernels. Thanks, Roland -- 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: [bug] uml doesn't boot under 2.6.25-rc1 host (was Re: 2.6.24-mm1 bugs)
On Thu, Feb 21, 2008 at 06:20:23PM +0100, Miklos Szeredi wrote: > Bisected it down to > > good e7b5e11eaaa8ef93a34e68016de51152d0d62911 > bad bde6f5f59c2b2b48a7a849c129d5b48838fe77ee > > I strongly suspect it's one of the ptrace cleanup patches. Roland, > could you please have a look? I agree. There's an awful lot of ptrace stuff in that range, and some of it apparently broke 32-bit compatibility. Thanks for chasing it down. Jeff -- Work email - jdike at linux dot intel dot com -- 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: [bug] uml doesn't boot under 2.6.25-rc1 host (was Re: 2.6.24-mm1 bugs)
> > > > - UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any > > > >other. Same guest boots fine on 2.6.24 host. > > > > > > What does it do? > > > > See below. > > This bug seems to have made it to mainline as well, starting with > -rc1. Any ideas? Should I start bisecting? Bisected it down to good e7b5e11eaaa8ef93a34e68016de51152d0d62911 bad bde6f5f59c2b2b48a7a849c129d5b48838fe77ee I strongly suspect it's one of the ptrace cleanup patches. Roland, could you please have a look? I'm running 32bit UML on 64bit host, this may have to do with triggering this, otherwise perhaps more people would have complained. Thanks, Miklos > > GNU gdb 6.6.50.20070726-cvs > > Copyright (C) 2007 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "x86_64-suse-linux"... > > Using host libthread_db library "/lib64/libthread_db.so.1". > > (gdb) r umid=uml > > Starting program: /store/quilt/linux/linux umid=uml > > Core dump limits : > > soft - 0 > > hard - NONE > > Checking that ptrace can change system call numbers...OK > > Checking syscall emulation patch for ptrace...missing > > Checking for tmpfs mount on /dev/shm...nothing mounted on /dev/shm > > Checking PROT_EXEC mmap in /tmp/...OK > > Checking for the skas3 patch in the host: > > - /proc/mm...not found: No such file or directory > > - PTRACE_FAULTINFO...not found: Invalid argument > > - PTRACE_LDT...not found: Invalid argument > > UML running in SKAS0 mode > > Adding 24977408 bytes to physical memory to account for exec-shield gap > > [0.00] Linux version 2.6.24-mm1 ([EMAIL PROTECTED]) (gcc version > > 4.2.1 (SUSE Linux)) #26 Fri Feb 15 11:05:54 CET 2008 > > [0.01] Built 1 zonelists in Zone order, mobility grouping on. > > Total pages: 14179 > > [0.01] Kernel command line: root=98:0 > > [0.01] PID hash table entries: 256 (order: 8, 1024 bytes) > > [0.01] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) > > [0.01] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) > > [0.01] Memory: 29504k available > > [0.27] Mount-cache hash table entries: 512 > > [0.27] Checking for host processor cmov support...Yes > > [0.27] Checking that host ptys support output SIGIO...Yes > > [0.27] Checking that host ptys support SIGIO on close...No, > > enabling workaround > > [0.27] net_namespace: 184 bytes > > [0.27] Using 2.6 host AIO > > [0.27] NET: Registered protocol family 16 > > [0.30] NET: Registered protocol family 2 > > [0.31] Time: itimer clocksource has been installed. > > [0.39] IP route cache hash table entries: 1024 (order: 0, 4096 > > bytes) > > [0.39] TCP established hash table entries: 2048 (order: 2, 16384 > > bytes) > > [0.39] TCP bind hash table entries: 2048 (order: 3, 40960 bytes) > > [0.39] TCP: Hash tables configured (established 2048 bind 2048) > > [0.39] TCP reno registered > > [0.42] Checking host MADV_REMOVE support...<3>MADV_REMOVE failed, > > err = -38 > > [0.42] Can't release memory to the host - memory hotplug won't be > > supported > > [0.42] mconsole (version 2) initialized on > > /home/mszeredi/.uml/uml/mconsole > > [0.42] Host TLS support detected > > [0.42] Detected host type: x86_64 (GDT indexes 12 to 15) > > [0.42] fuse init (API version 7.9) > > [0.42] io scheduler noop registered (default) > > [0.42] loop: module loaded > > [0.42] TCP cubic registered > > [0.42] NET: Registered protocol family 1 > > [0.42] Initialized stdio console driver > > [0.42] Console initialized on /dev/tty0 > > [0.42] console [tty0] enabled > > [0.42] console [mc-1] enabled > > [0.42] ubda: unknown partition table > > [0.42] kjournald starting. Commit interval 5 seconds > > [0.42] EXT3-fs: mounted filesystem with ordered data mode. > > [0.42] VFS: Mounted root (ext3 filesystem) readonly. > > [0.42] Failed to get registers from stub, errno = 3 > > [0.42] wait_stub_done : failed to wait for SIGTRAP, pid = 30073, n > > = 30073, errno = 0, status = 0x0 > > [New LWP 30070] > >[New LWP 30071] > > [New LWP 30072] > > > > Program received signal SIGTERM, Terminated. > > 0xe430 in __kernel_vsyscall () > > (gdb) bt > > #0 0xe430 in __kernel_vsyscall () > > #1 0xf7eabc26 in kill () from /lib/libc.so.6 > > #2 0x0806cf82 in os_dump_core () at arch/um/os-Linux/util.c:105 > > #3 0x0805d64d in fatal_sigsegv () at
Re: [bug] uml doesn't boot under 2.6.25-rc1 host (was Re: 2.6.24-mm1 bugs)
- UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any other. Same guest boots fine on 2.6.24 host. What does it do? See below. This bug seems to have made it to mainline as well, starting with -rc1. Any ideas? Should I start bisecting? Bisected it down to good e7b5e11eaaa8ef93a34e68016de51152d0d62911 bad bde6f5f59c2b2b48a7a849c129d5b48838fe77ee I strongly suspect it's one of the ptrace cleanup patches. Roland, could you please have a look? I'm running 32bit UML on 64bit host, this may have to do with triggering this, otherwise perhaps more people would have complained. Thanks, Miklos GNU gdb 6.6.50.20070726-cvs Copyright (C) 2007 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-suse-linux... Using host libthread_db library /lib64/libthread_db.so.1. (gdb) r umid=uml Starting program: /store/quilt/linux/linux umid=uml Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...missing Checking for tmpfs mount on /dev/shm...nothing mounted on /dev/shm Checking PROT_EXEC mmap in /tmp/...OK Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO...not found: Invalid argument - PTRACE_LDT...not found: Invalid argument UML running in SKAS0 mode Adding 24977408 bytes to physical memory to account for exec-shield gap [0.00] Linux version 2.6.24-mm1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (SUSE Linux)) #26 Fri Feb 15 11:05:54 CET 2008 [0.01] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 14179 [0.01] Kernel command line: root=98:0 [0.01] PID hash table entries: 256 (order: 8, 1024 bytes) [0.01] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [0.01] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [0.01] Memory: 29504k available [0.27] Mount-cache hash table entries: 512 [0.27] Checking for host processor cmov support...Yes [0.27] Checking that host ptys support output SIGIO...Yes [0.27] Checking that host ptys support SIGIO on close...No, enabling workaround [0.27] net_namespace: 184 bytes [0.27] Using 2.6 host AIO [0.27] NET: Registered protocol family 16 [0.30] NET: Registered protocol family 2 [0.31] Time: itimer clocksource has been installed. [0.39] IP route cache hash table entries: 1024 (order: 0, 4096 bytes) [0.39] TCP established hash table entries: 2048 (order: 2, 16384 bytes) [0.39] TCP bind hash table entries: 2048 (order: 3, 40960 bytes) [0.39] TCP: Hash tables configured (established 2048 bind 2048) [0.39] TCP reno registered [0.42] Checking host MADV_REMOVE support...3MADV_REMOVE failed, err = -38 [0.42] Can't release memory to the host - memory hotplug won't be supported [0.42] mconsole (version 2) initialized on /home/mszeredi/.uml/uml/mconsole [0.42] Host TLS support detected [0.42] Detected host type: x86_64 (GDT indexes 12 to 15) [0.42] fuse init (API version 7.9) [0.42] io scheduler noop registered (default) [0.42] loop: module loaded [0.42] TCP cubic registered [0.42] NET: Registered protocol family 1 [0.42] Initialized stdio console driver [0.42] Console initialized on /dev/tty0 [0.42] console [tty0] enabled [0.42] console [mc-1] enabled [0.42] ubda: unknown partition table [0.42] kjournald starting. Commit interval 5 seconds [0.42] EXT3-fs: mounted filesystem with ordered data mode. [0.42] VFS: Mounted root (ext3 filesystem) readonly. [0.42] Failed to get registers from stub, errno = 3 [0.42] wait_stub_done : failed to wait for SIGTRAP, pid = 30073, n = 30073, errno = 0, status = 0x0 [New LWP 30070] [New LWP 30071] [New LWP 30072] Program received signal SIGTERM, Terminated. 0xe430 in __kernel_vsyscall () (gdb) bt #0 0xe430 in __kernel_vsyscall () #1 0xf7eabc26 in kill () from /lib/libc.so.6 #2 0x0806cf82 in os_dump_core () at arch/um/os-Linux/util.c:105 #3 0x0805d64d in fatal_sigsegv () at arch/um/kernel/trap.c:141 #4 0x0806e32b in wait_stub_done (pid=30073) at arch/um/os-Linux/skas/process.c:94 #5 0x0806d94b in run_syscall_stub (mm_idp=0xb26ff18, syscall=123, args=0xb067e08,
Re: [bug] uml doesn't boot under 2.6.25-rc1 host (was Re: 2.6.24-mm1 bugs)
On Thu, Feb 21, 2008 at 06:20:23PM +0100, Miklos Szeredi wrote: Bisected it down to good e7b5e11eaaa8ef93a34e68016de51152d0d62911 bad bde6f5f59c2b2b48a7a849c129d5b48838fe77ee I strongly suspect it's one of the ptrace cleanup patches. Roland, could you please have a look? I agree. There's an awful lot of ptrace stuff in that range, and some of it apparently broke 32-bit compatibility. Thanks for chasing it down. Jeff -- Work email - jdike at linux dot intel dot com -- 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: [bug] uml doesn't boot under 2.6.25-rc1 host (was Re: 2.6.24-mm1 bugs)
Thanks for the pointers, guys. It took a while for me to figure out what got wrong to foul up UML, but the bug and fix are trivial (posting now). Some of the testing I thought had got done clearly wasn't done, since PTRACE_SETREGS was 100% busticated for 32-bit processes calling ptrace on x86_64 kernels. Thanks, Roland -- 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/
[bug] uml doesn't boot under 2.6.25-rc1 host (was Re: 2.6.24-mm1 bugs)
> > > - UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any > > >other. Same guest boots fine on 2.6.24 host. > > > > What does it do? > > See below. This bug seems to have made it to mainline as well, starting with -rc1. Any ideas? Should I start bisecting? Thanks, Miklos > > > > > Any chance you can bisect it? > > It would be a bit painful, because this is the only machine I can use. > I much prefer bisecting UML kernels :) > > Thanks, > Miklos > > > > > GNU gdb 6.6.50.20070726-cvs > Copyright (C) 2007 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "x86_64-suse-linux"... > Using host libthread_db library "/lib64/libthread_db.so.1". > (gdb) r umid=uml > Starting program: /store/quilt/linux/linux umid=uml > Core dump limits : > soft - 0 > hard - NONE > Checking that ptrace can change system call numbers...OK > Checking syscall emulation patch for ptrace...missing > Checking for tmpfs mount on /dev/shm...nothing mounted on /dev/shm > Checking PROT_EXEC mmap in /tmp/...OK > Checking for the skas3 patch in the host: > - /proc/mm...not found: No such file or directory > - PTRACE_FAULTINFO...not found: Invalid argument > - PTRACE_LDT...not found: Invalid argument > UML running in SKAS0 mode > Adding 24977408 bytes to physical memory to account for exec-shield gap > [0.00] Linux version 2.6.24-mm1 ([EMAIL PROTECTED]) (gcc version > 4.2.1 (SUSE Linux)) #26 Fri Feb 15 11:05:54 CET 2008 > [0.01] Built 1 zonelists in Zone order, mobility grouping on. Total > pages: 14179 > [0.01] Kernel command line: root=98:0 > [0.01] PID hash table entries: 256 (order: 8, 1024 bytes) > [0.01] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) > [0.01] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) > [0.01] Memory: 29504k available > [0.27] Mount-cache hash table entries: 512 > [0.27] Checking for host processor cmov support...Yes > [0.27] Checking that host ptys support output SIGIO...Yes > [0.27] Checking that host ptys support SIGIO on close...No, enabling > workaround > [0.27] net_namespace: 184 bytes > [0.27] Using 2.6 host AIO > [0.27] NET: Registered protocol family 16 > [0.30] NET: Registered protocol family 2 > [0.31] Time: itimer clocksource has been installed. > [0.39] IP route cache hash table entries: 1024 (order: 0, 4096 bytes) > [0.39] TCP established hash table entries: 2048 (order: 2, 16384 > bytes) > [0.39] TCP bind hash table entries: 2048 (order: 3, 40960 bytes) > [0.39] TCP: Hash tables configured (established 2048 bind 2048) > [0.39] TCP reno registered > [0.42] Checking host MADV_REMOVE support...<3>MADV_REMOVE failed, err > = -38 > [0.42] Can't release memory to the host - memory hotplug won't be > supported > [0.42] mconsole (version 2) initialized on > /home/mszeredi/.uml/uml/mconsole > [0.42] Host TLS support detected > [0.42] Detected host type: x86_64 (GDT indexes 12 to 15) > [0.42] fuse init (API version 7.9) > [0.42] io scheduler noop registered (default) > [0.42] loop: module loaded > [0.42] TCP cubic registered > [0.42] NET: Registered protocol family 1 > [0.42] Initialized stdio console driver > [0.42] Console initialized on /dev/tty0 > [0.42] console [tty0] enabled > [0.42] console [mc-1] enabled > [0.42] ubda: unknown partition table > [0.42] kjournald starting. Commit interval 5 seconds > [0.42] EXT3-fs: mounted filesystem with ordered data mode. > [0.42] VFS: Mounted root (ext3 filesystem) readonly. > [0.42] Failed to get registers from stub, errno = 3 > [0.42] wait_stub_done : failed to wait for SIGTRAP, pid = 30073, n = > 30073, errno = 0, status = 0x0 > [New LWP 30070] >[New LWP 30071] > [New LWP 30072] > > Program received signal SIGTERM, Terminated. > 0xe430 in __kernel_vsyscall () > (gdb) bt > #0 0xe430 in __kernel_vsyscall () > #1 0xf7eabc26 in kill () from /lib/libc.so.6 > #2 0x0806cf82 in os_dump_core () at arch/um/os-Linux/util.c:105 > #3 0x0805d64d in fatal_sigsegv () at arch/um/kernel/trap.c:141 > #4 0x0806e32b in wait_stub_done (pid=30073) > at arch/um/os-Linux/skas/process.c:94 > #5 0x0806d94b in run_syscall_stub (mm_idp=0xb26ff18, syscall=123, > args=0xb067e08, expected=0, addr=0xb067ea4, done=1) > at arch/um/os-Linux/skas/mem.c:86 > #6 0x0806f997 in write_ldt_entry (mm_idp=0xb26ff18, func=1, desc=0xb067e94,
Re: 2.6.24-mm1 bugs
> > - strange key repeating (short press of a key results in lots of key > >press events) when there's some sort of load (I/O?) I may have > >seen this on non-mm kernels as well, but it's definitely more > >noticable in -mm > > Do you have CONFIG_FAIR_GROUP_SCHED enabled?, if so, does disabling it > make it go away? I haven't experienced this since disabling CONFIG_FAIR_GROUP_SCHED. What's more, the network problems have also gone away. Since I haven't done extensive testing, this may just be coincidence. Let me know if you need more info. Thanks, Miklos -- 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.24-mm1 bugs
- strange key repeating (short press of a key results in lots of key press events) when there's some sort of load (I/O?) I may have seen this on non-mm kernels as well, but it's definitely more noticable in -mm Do you have CONFIG_FAIR_GROUP_SCHED enabled?, if so, does disabling it make it go away? I haven't experienced this since disabling CONFIG_FAIR_GROUP_SCHED. What's more, the network problems have also gone away. Since I haven't done extensive testing, this may just be coincidence. Let me know if you need more info. Thanks, Miklos -- 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/
[bug] uml doesn't boot under 2.6.25-rc1 host (was Re: 2.6.24-mm1 bugs)
- UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any other. Same guest boots fine on 2.6.24 host. What does it do? See below. This bug seems to have made it to mainline as well, starting with -rc1. Any ideas? Should I start bisecting? Thanks, Miklos Any chance you can bisect it? It would be a bit painful, because this is the only machine I can use. I much prefer bisecting UML kernels :) Thanks, Miklos GNU gdb 6.6.50.20070726-cvs Copyright (C) 2007 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-suse-linux... Using host libthread_db library /lib64/libthread_db.so.1. (gdb) r umid=uml Starting program: /store/quilt/linux/linux umid=uml Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...missing Checking for tmpfs mount on /dev/shm...nothing mounted on /dev/shm Checking PROT_EXEC mmap in /tmp/...OK Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO...not found: Invalid argument - PTRACE_LDT...not found: Invalid argument UML running in SKAS0 mode Adding 24977408 bytes to physical memory to account for exec-shield gap [0.00] Linux version 2.6.24-mm1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (SUSE Linux)) #26 Fri Feb 15 11:05:54 CET 2008 [0.01] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 14179 [0.01] Kernel command line: root=98:0 [0.01] PID hash table entries: 256 (order: 8, 1024 bytes) [0.01] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [0.01] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [0.01] Memory: 29504k available [0.27] Mount-cache hash table entries: 512 [0.27] Checking for host processor cmov support...Yes [0.27] Checking that host ptys support output SIGIO...Yes [0.27] Checking that host ptys support SIGIO on close...No, enabling workaround [0.27] net_namespace: 184 bytes [0.27] Using 2.6 host AIO [0.27] NET: Registered protocol family 16 [0.30] NET: Registered protocol family 2 [0.31] Time: itimer clocksource has been installed. [0.39] IP route cache hash table entries: 1024 (order: 0, 4096 bytes) [0.39] TCP established hash table entries: 2048 (order: 2, 16384 bytes) [0.39] TCP bind hash table entries: 2048 (order: 3, 40960 bytes) [0.39] TCP: Hash tables configured (established 2048 bind 2048) [0.39] TCP reno registered [0.42] Checking host MADV_REMOVE support...3MADV_REMOVE failed, err = -38 [0.42] Can't release memory to the host - memory hotplug won't be supported [0.42] mconsole (version 2) initialized on /home/mszeredi/.uml/uml/mconsole [0.42] Host TLS support detected [0.42] Detected host type: x86_64 (GDT indexes 12 to 15) [0.42] fuse init (API version 7.9) [0.42] io scheduler noop registered (default) [0.42] loop: module loaded [0.42] TCP cubic registered [0.42] NET: Registered protocol family 1 [0.42] Initialized stdio console driver [0.42] Console initialized on /dev/tty0 [0.42] console [tty0] enabled [0.42] console [mc-1] enabled [0.42] ubda: unknown partition table [0.42] kjournald starting. Commit interval 5 seconds [0.42] EXT3-fs: mounted filesystem with ordered data mode. [0.42] VFS: Mounted root (ext3 filesystem) readonly. [0.42] Failed to get registers from stub, errno = 3 [0.42] wait_stub_done : failed to wait for SIGTRAP, pid = 30073, n = 30073, errno = 0, status = 0x0 [New LWP 30070] [New LWP 30071] [New LWP 30072] Program received signal SIGTERM, Terminated. 0xe430 in __kernel_vsyscall () (gdb) bt #0 0xe430 in __kernel_vsyscall () #1 0xf7eabc26 in kill () from /lib/libc.so.6 #2 0x0806cf82 in os_dump_core () at arch/um/os-Linux/util.c:105 #3 0x0805d64d in fatal_sigsegv () at arch/um/kernel/trap.c:141 #4 0x0806e32b in wait_stub_done (pid=30073) at arch/um/os-Linux/skas/process.c:94 #5 0x0806d94b in run_syscall_stub (mm_idp=0xb26ff18, syscall=123, args=0xb067e08, expected=0, addr=0xb067ea4, done=1) at arch/um/os-Linux/skas/mem.c:86 #6 0x0806f997 in write_ldt_entry (mm_idp=0xb26ff18, func=1, desc=0xb067e94, addr=0xb067ea4, done=1) at arch/um/sys-i386/ldt.c:72 #7 0x08070434 in init_new_ldt (new_mm=0xb26ff18, from_mm=0x0)
Re: 2.6.24-mm1 bugs
> On Fri, Feb 15, 2008 at 08:52:04PM +0100, Miklos Szeredi wrote: > > > What does it do? > > > > See below. > > > [0.42] Checking host MADV_REMOVE support...<3>MADV_REMOVE failed, > > err = -38 > > Where'd MADV_REMOVE go? I have it on 2.6.24. Oh, I always get this message. Looking closer, this only works if /tmp is tmpfs. Which isn't in most cases. > > [0.42] Failed to get registers from stub, errno = 3 > > [0.42] wait_stub_done : failed to wait for SIGTRAP, pid = 30073, n > > = 30073, errno = 0, status = 0x0 > > Is utrace in there, by any chance? When I see crazy stuff like this, > I think utrace. Nope. Must be some other crazy stuff :) Miklos -- 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.24-mm1 bugs
On Fri, Feb 15, 2008 at 08:52:04PM +0100, Miklos Szeredi wrote: > > What does it do? > > See below. > [0.42] Checking host MADV_REMOVE support...<3>MADV_REMOVE failed, err > = -38 Where'd MADV_REMOVE go? I have it on 2.6.24. > [0.42] Failed to get registers from stub, errno = 3 > [0.42] wait_stub_done : failed to wait for SIGTRAP, pid = 30073, n = > 30073, errno = 0, status = 0x0 Is utrace in there, by any chance? When I see crazy stuff like this, I think utrace. Jeff -- Work email - jdike at linux dot intel dot com -- 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: isofs - Re: 2.6.24-mm1 bugs
On Fri, 15 Feb 2008 11:46:55 -0500
[EMAIL PROTECTED] wrote:
> On Fri, 15 Feb 2008 12:43:45 +0100, Miklos Szeredi said:
> > I'm trying out 2.6.24-mm1 on my work laptop (T60), and generally it
>
> > - mounting isofs always results in an empty directory
>
> I hit this in 24-rc8-mm1, and bisected it down to
> iget-stop-isofs-from-using-read_inode-fix-2.patch
>
> Apparently it got broken way back in 24-rc6-mm1.
>
> And that directory is *really* empty - even . and .. are missing. :)
>
Seems that 2.6.24-mm1+hot-fixes still didn't have
iget-stop-isofs-from-using-read_inode-fix-3.patch:
From: David Howells <[EMAIL PROTECTED]>
Fix isofs_get_block() to return only 0 on success. It shouldn't return a
+ve block count for example.
Also make sure that isofs_get_blocks() doesn't accidentally return an error
if rv is 0 come the return statement.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
fs/isofs/inode.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff -puN fs/isofs/inode.c~iget-stop-isofs-from-using-read_inode-fix-3
fs/isofs/inode.c
--- a/fs/isofs/inode.c~iget-stop-isofs-from-using-read_inode-fix-3
+++ a/fs/isofs/inode.c
@@ -1022,6 +1022,7 @@ int isofs_get_blocks(struct inode *inode
rv++;
}
+ error = 0;
abort:
unlock_kernel();
return rv != 0 ? rv : error;
@@ -1033,12 +1034,15 @@ abort:
static int isofs_get_block(struct inode *inode, sector_t iblock,
struct buffer_head *bh_result, int create)
{
+ int ret;
+
if (create) {
printk(KERN_DEBUG "%s: Kernel tries to allocate a block\n",
__func__);
return -EROFS;
}
- return isofs_get_blocks(inode, iblock, _result, 1);
+ ret = isofs_get_blocks(inode, iblock, _result, 1);
+ return ret < 0 ? ret : 0;
}
static int isofs_bmap(struct inode *inode, sector_t block)
_
--
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.24-mm1 bugs
On Friday 15 February 2008, Miklos Szeredi wrote: > > > - UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any > > >other. Same guest boots fine on 2.6.24 host. > > > > What does it do? > > See below. > > > > > Any chance you can bisect it? > > It would be a bit painful, because this is the only machine I can use. > I much prefer bisecting UML kernels :) Is it possible to bisect uml kernels inside qemu? :) Thanks, Bart -- 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.24-mm1 bugs
> > - UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any > >other. Same guest boots fine on 2.6.24 host. > > What does it do? See below. > > Any chance you can bisect it? It would be a bit painful, because this is the only machine I can use. I much prefer bisecting UML kernels :) Thanks, Miklos GNU gdb 6.6.50.20070726-cvs Copyright (C) 2007 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-suse-linux"... Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) r umid=uml Starting program: /store/quilt/linux/linux umid=uml Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...missing Checking for tmpfs mount on /dev/shm...nothing mounted on /dev/shm Checking PROT_EXEC mmap in /tmp/...OK Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO...not found: Invalid argument - PTRACE_LDT...not found: Invalid argument UML running in SKAS0 mode Adding 24977408 bytes to physical memory to account for exec-shield gap [0.00] Linux version 2.6.24-mm1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (SUSE Linux)) #26 Fri Feb 15 11:05:54 CET 2008 [0.01] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 14179 [0.01] Kernel command line: root=98:0 [0.01] PID hash table entries: 256 (order: 8, 1024 bytes) [0.01] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [0.01] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [0.01] Memory: 29504k available [0.27] Mount-cache hash table entries: 512 [0.27] Checking for host processor cmov support...Yes [0.27] Checking that host ptys support output SIGIO...Yes [0.27] Checking that host ptys support SIGIO on close...No, enabling workaround [0.27] net_namespace: 184 bytes [0.27] Using 2.6 host AIO [0.27] NET: Registered protocol family 16 [0.30] NET: Registered protocol family 2 [0.31] Time: itimer clocksource has been installed. [0.39] IP route cache hash table entries: 1024 (order: 0, 4096 bytes) [0.39] TCP established hash table entries: 2048 (order: 2, 16384 bytes) [0.39] TCP bind hash table entries: 2048 (order: 3, 40960 bytes) [0.39] TCP: Hash tables configured (established 2048 bind 2048) [0.39] TCP reno registered [0.42] Checking host MADV_REMOVE support...<3>MADV_REMOVE failed, err = -38 [0.42] Can't release memory to the host - memory hotplug won't be supported [0.42] mconsole (version 2) initialized on /home/mszeredi/.uml/uml/mconsole [0.42] Host TLS support detected [0.42] Detected host type: x86_64 (GDT indexes 12 to 15) [0.42] fuse init (API version 7.9) [0.42] io scheduler noop registered (default) [0.42] loop: module loaded [0.42] TCP cubic registered [0.42] NET: Registered protocol family 1 [0.42] Initialized stdio console driver [0.42] Console initialized on /dev/tty0 [0.42] console [tty0] enabled [0.42] console [mc-1] enabled [0.42] ubda: unknown partition table [0.42] kjournald starting. Commit interval 5 seconds [0.42] EXT3-fs: mounted filesystem with ordered data mode. [0.42] VFS: Mounted root (ext3 filesystem) readonly. [0.42] Failed to get registers from stub, errno = 3 [0.42] wait_stub_done : failed to wait for SIGTRAP, pid = 30073, n = 30073, errno = 0, status = 0x0 [New LWP 30070] [New LWP 30071] [New LWP 30072] Program received signal SIGTERM, Terminated. 0xe430 in __kernel_vsyscall () (gdb) bt #0 0xe430 in __kernel_vsyscall () #1 0xf7eabc26 in kill () from /lib/libc.so.6 #2 0x0806cf82 in os_dump_core () at arch/um/os-Linux/util.c:105 #3 0x0805d64d in fatal_sigsegv () at arch/um/kernel/trap.c:141 #4 0x0806e32b in wait_stub_done (pid=30073) at arch/um/os-Linux/skas/process.c:94 #5 0x0806d94b in run_syscall_stub (mm_idp=0xb26ff18, syscall=123, args=0xb067e08, expected=0, addr=0xb067ea4, done=1) at arch/um/os-Linux/skas/mem.c:86 #6 0x0806f997 in write_ldt_entry (mm_idp=0xb26ff18, func=1, desc=0xb067e94, addr=0xb067ea4, done=1) at arch/um/sys-i386/ldt.c:72 #7 0x08070434 in init_new_ldt (new_mm=0xb26ff18, from_mm=0x0) at arch/um/sys-i386/ldt.c:425 #8 0x0805de43 in init_new_context (task=0xb05bc00, mm=0xb26fdc0) at arch/um/kernel/skas/mmu.c:87 #9 0x080ce3c1 in bprm_mm_init (bprm=0xb1a6980) at fs/exec.c:337 #10 0x080cfa2d in
Re: 2.6.24-mm1 bugs
On Fri, Feb 15, 2008 at 12:43:45PM +0100, Miklos Szeredi wrote: > - UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any >other. Same guest boots fine on 2.6.24 host. What does it do? Any chance you can bisect it? Jeff -- Work email - jdike at linux dot intel dot com -- 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.24-mm1 bugs
Miklos Szeredi wrote: >> the register dump looks OK as far as I can see. Since initialization >> works OK and the adapter seems to be setup OK reading from the >> register dump, I'm not sure at all what is going on. >> >> can you try manually ifup-ing the device and running tcpdump? do you >> see packets coming in? > > Well it does seem to receive the DHCP reply. > >> just for kicks, have you tried a different cable? or is the adapter >> consistently working properly using a different kernel/driver? > > It has been consistently working properly for a long time with various > kernels (and the e1000 driver). I've now swithed to 2.6.24-mm1 and > e1000e, and it's almost consistently broken after boot and resume, and > sometimes needs several tries (with the KDE NetworkManager thingy) to > make it work. maybe it's worth trying linux-2.6.git instead for now? The e1000e driver is actually involved in the dhcp handshake so we can't just rule a bug out yet. However, with my own t60 things appear to work just fine. how does manually getting a dhcp address go? can you eliminate networkmanager perhaps? just kill & restart dhclient over and over again... Auke -- 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.24-mm1 bugs
> the register dump looks OK as far as I can see. Since initialization > works OK and the adapter seems to be setup OK reading from the > register dump, I'm not sure at all what is going on. > > can you try manually ifup-ing the device and running tcpdump? do you > see packets coming in? Well it does seem to receive the DHCP reply. > > just for kicks, have you tried a different cable? or is the adapter > consistently working properly using a different kernel/driver? It has been consistently working properly for a long time with various kernels (and the e1000 driver). I've now swithed to 2.6.24-mm1 and e1000e, and it's almost consistently broken after boot and resume, and sometimes needs several tries (with the KDE NetworkManager thingy) to make it work. My guess is that either NetworkManager is buggy, or there's something else in -mm that's breaking NetworkManager. But now it does seem unlikely to be an ethernet driver issue. Thanks, Miklos -- 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.24-mm1 bugs
Miklos Szeredi wrote: >> OK. can you download, install and run `ethregs -i eth0` (from >> e1000.sf.net) and send me the output? I'll compare with a known >> working t60 I have here and see if anything shows up. > > OK, attached. > >> Also, post me the dmesg from after the adapter fails to load >> properly. > > Hmm, nothing in dmesg. Looking at syslog, I'm not even sure it's a > driver issue, it could also be dhclient or NetworkManager bug. The > strange thing is that this only happens on -mm. > > These are the relevant syslog messages for an unsuccessful attempt: > > == > Feb 15 12:27:32 tucsk kernel: [ 35.169183] :02:00.0: eth0: Link is Up > 100 Mbps Full Duplex, Flow Control: RX/TX > Feb 15 12:27:32 tucsk kernel: [ 35.169190] :02:00.0: eth0: 10/100 > speed: disabling TSO > Feb 15 12:27:40 tucsk dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port > 67 interval 4 > Feb 15 12:27:40 tucsk dhclient: DHCPOFFER from 192.168.0.1 > Feb 15 12:27:45 tucsk dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 > Feb 15 12:27:45 tucsk dhclient: DHCPACK from 192.168.0.1 > Feb 15 12:27:46 tucsk dhclient: bound to 192.168.0.9 -- renewal in 1539 > seconds. > Feb 15 12:28:20 tucsk dhclient: caught deadly SIGTERM > Feb 15 12:28:20 tucsk dhclient: could not restore resolv.conf: No such file > or directory > Feb 15 12:28:20 tucsk dhclient: DHCPRELEASE on eth0 to 192.168.0.1 port 67 > Feb 15 12:28:20 tucsk dhclient: send_packet: Network is unreachable > Feb 15 12:28:20 tucsk dhclient: send_packet: please consult README file > regarding broadcast address. > == > > And then for the successful one: > > == > Feb 15 12:29:17 tucsk dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port > 67 interval 2 > Feb 15 12:29:17 tucsk dhclient: DHCPOFFER from 192.168.0.1 > Feb 15 12:29:22 tucsk dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 > Feb 15 12:29:22 tucsk dhclient: DHCPACK from 192.168.0.1 > Feb 15 12:29:22 tucsk dhclient: bound to 192.168.0.9 -- renewal in 1543 > seconds. > == > > Thanks, > Miklos > > > > 02:00.0 (8086:109a) > Unknown device 8086:109a > Name Value > ~ > CTRL 18140248 the register dump looks OK as far as I can see. Since initialization works OK and the adapter seems to be setup OK reading from the register dump, I'm not sure at all what is going on. can you try manually ifup-ing the device and running tcpdump? do you see packets coming in? just for kicks, have you tried a different cable? or is the adapter consistently working properly using a different kernel/driver? Auke -- 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.24-mm1 bugs
And here's the NetworkManager side of the log: == Feb 15 12:27:30 tucsk NetworkManager: starting... Feb 15 12:27:30 tucsk NetworkManager: [1203074850.429242] nm_system_device_get_system_config(): found config '/etc/sysconfig/network/ifcfg-eth0' for interface 'eth0' Feb 15 12:27:30 tucsk NetworkManager: [1203074850.429334] nm_system_device_get_system_config(): BOOTPROTO=dhcp Feb 15 12:27:30 tucsk NetworkManager: [1203074850.429373] nm_system_device_get_system_config(): -- Config (eth0) Feb 15 12:27:30 tucsk NetworkManager: [1203074850.429392] nm_system_device_get_system_config(): dhcp=1 Feb 15 12:27:30 tucsk NetworkManager: [1203074850.429423] nm_system_device_get_system_config(): addr=0.0.0.0 Feb 15 12:27:30 tucsk NetworkManager: [1203074850.429441] nm_system_device_get_system_config(): gw=0.0.0.0 Feb 15 12:27:30 tucsk NetworkManager: [1203074850.429458] nm_system_device_get_system_config(): mask=0.0.0.0 Feb 15 12:27:30 tucsk NetworkManager: [1203074850.429476] nm_system_device_get_system_config(): - Feb 15 12:27:30 tucsk NetworkManager: eth0: Device is fully-supported using driver 'e1000e'. Feb 15 12:27:30 tucsk NetworkManager: nm_device_init(): waiting for device's worker thread to start Feb 15 12:27:30 tucsk NetworkManager: nm_device_init(): device's worker thread started, continuing. Feb 15 12:27:30 tucsk NetworkManager: Now managing wired Ethernet (802.3) device 'eth0'. Feb 15 12:27:30 tucsk NetworkManager: Deactivating device eth0. Feb 15 12:27:32 tucsk NetworkManager: Will activate wired connection 'eth0' because it now has a link. Feb 15 12:27:32 tucsk NetworkManager: SWITCH: no current connection, found better connection 'eth0'. Feb 15 12:27:33 tucsk NetworkManager: Will activate connection 'eth0'. Feb 15 12:27:33 tucsk NetworkManager: Device eth0 activation scheduled... Feb 15 12:27:33 tucsk NetworkManager: Activation (eth0) started... Feb 15 12:27:33 tucsk NetworkManager: Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... Feb 15 12:27:33 tucsk NetworkManager: Activation (eth0) Stage 1 of 5 (Device Prepare) started... Feb 15 12:27:33 tucsk NetworkManager: Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... Feb 15 12:27:33 tucsk NetworkManager: Activation (eth0) Stage 1 of 5 (Device Prepare) complete. Feb 15 12:27:33 tucsk NetworkManager: Activation (eth0) Stage 2 of 5 (Device Configure) starting... Feb 15 12:27:33 tucsk NetworkManager: Activation (eth0) Stage 2 of 5 (Device Configure) successful. Feb 15 12:27:33 tucsk NetworkManager: Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled. Feb 15 12:27:33 tucsk NetworkManager: Activation (eth0) Stage 2 of 5 (Device Configure) complete. Feb 15 12:27:33 tucsk NetworkManager: Activation (eth0) Stage 3 of 5 (IP Configure Start) started... Feb 15 12:27:35 tucsk NetworkManager: Activation (eth0) Beginning DHCP transaction. Feb 15 12:27:35 tucsk NetworkManager: Activation (eth0) Stage 3 of 5 (IP Configure Start) complete. Feb 15 12:27:35 tucsk NetworkManager: DHCP daemon state is now 12 (successfully started) for interface eth0 Feb 15 12:28:07 tucsk NetworkManager: Updating allowed wireless network lists. Feb 15 12:28:10 tucsk NetworkManager: Old device 'eth0' activating, won't change. Feb 15 12:28:20 tucsk NetworkManager: Device 'eth0' DHCP transaction took too long (>45s), stopping it. Feb 15 12:28:21 tucsk NetworkManager: Activation (eth0) Stage 4 of 5 (IP Configure Timeout) scheduled... Feb 15 12:28:21 tucsk NetworkManager: Activation (eth0) Stage 4 of 5 (IP Configure Timeout) started... Feb 15 12:28:21 tucsk NetworkManager: No DHCP reply received. Automatically obtaining IP via Zeroconf. == So it does indeed look like some communication problem between NetworkManager and dhclient, as NetworkManager thinks there was no DHCP reply when in fac there was one: == Feb 15 12:27:32 tucsk kernel: [ 35.169183] :02:00.0: eth0: Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX Feb 15 12:27:32 tucsk kernel: [ 35.169190] :02:00.0: eth0: 10/100 speed: disabling TSO Feb 15 12:27:40 tucsk dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 Feb 15 12:27:40 tucsk dhclient: DHCPOFFER from 192.168.0.1 Feb 15 12:27:45 tucsk dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Feb 15 12:27:45 tucsk dhclient: DHCPACK from 192.168.0.1 Feb 15 12:27:46 tucsk dhclient: bound to 192.168.0.9 -- renewal in 1539 seconds. Feb 15 12:28:20 tucsk dhclient: caught deadly SIGTERM Feb 15 12:28:20 tucsk dhclient: could not restore resolv.conf: No such file or directory Feb 15 12:28:20 tucsk dhclient: DHCPRELEASE on eth0 to 192.168.0.1 port 67 Feb 15 12:28:20 tucsk dhclient:
Re: 2.6.24-mm1 bugs
> OK. can you download, install and run `ethregs -i eth0` (from > e1000.sf.net) and send me the output? I'll compare with a known > working t60 I have here and see if anything shows up. OK, attached. > Also, post me the dmesg from after the adapter fails to load > properly. Hmm, nothing in dmesg. Looking at syslog, I'm not even sure it's a driver issue, it could also be dhclient or NetworkManager bug. The strange thing is that this only happens on -mm. These are the relevant syslog messages for an unsuccessful attempt: == Feb 15 12:27:32 tucsk kernel: [ 35.169183] :02:00.0: eth0: Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX Feb 15 12:27:32 tucsk kernel: [ 35.169190] :02:00.0: eth0: 10/100 speed: disabling TSO Feb 15 12:27:40 tucsk dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 Feb 15 12:27:40 tucsk dhclient: DHCPOFFER from 192.168.0.1 Feb 15 12:27:45 tucsk dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Feb 15 12:27:45 tucsk dhclient: DHCPACK from 192.168.0.1 Feb 15 12:27:46 tucsk dhclient: bound to 192.168.0.9 -- renewal in 1539 seconds. Feb 15 12:28:20 tucsk dhclient: caught deadly SIGTERM Feb 15 12:28:20 tucsk dhclient: could not restore resolv.conf: No such file or directory Feb 15 12:28:20 tucsk dhclient: DHCPRELEASE on eth0 to 192.168.0.1 port 67 Feb 15 12:28:20 tucsk dhclient: send_packet: Network is unreachable Feb 15 12:28:20 tucsk dhclient: send_packet: please consult README file regarding broadcast address. == And then for the successful one: == Feb 15 12:29:17 tucsk dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 2 Feb 15 12:29:17 tucsk dhclient: DHCPOFFER from 192.168.0.1 Feb 15 12:29:22 tucsk dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Feb 15 12:29:22 tucsk dhclient: DHCPACK from 192.168.0.1 Feb 15 12:29:22 tucsk dhclient: bound to 192.168.0.9 -- renewal in 1543 seconds. == Thanks, Miklos 02:00.0 (8086:109a) Unknown device 8086:109a Name Value ~ CTRL 18140248 STATUS 80080743 EECD 06008318 EERD 00510016 CTRL_EXT 2878 FLA0600 MDIC 18316d4c FCAL 00c28001 FCAH 0100 FCT8808 VET8100 ITR03d0 ICS IMS009d IMC009d IAM RCTL 8002 FCTTV 0680 TCTL 3103f0fa TIPG 00602008 AIT LEDCTL 000f8b02 EXTCNF_CTRL0014000a EXTCNF_SIZE0004 PBA000c0014 PBS0020 EEMNGCTL 8000 EEARBC 001d0290 FLASHT 0002 EEWR 0002 FLSWCTLc000 FLSWDATA FLSWCNT FLOP 0004db00 ERT FCRTL 800047f8 FCRTH 4800 PSRCTL 00040402 RDBAL 22346000 RDBAH RDLEN 1000 RDH00ee RDT00ec RDTR RXDCTL 0001 RADV 0008 RDBAL1 0410 RDBAH1 1200 RDLEN1 RDH1 RDT1 RSRPD RAID CPUVEC TDFH 0d00 TDFT 0d00 TDFHS 0d00 TDFTS 0d00 TDFPC TDBAL 3cc46000 TDBAH TDLEN 1000 TDH0002 TDT0002 TIDV 0008 TXDCTL 0141 TADV 0020 TARC0 0403 TDBAL1 9840 TDBAH1 12002000 TDLEN1 TDH1 TDT1 TXDCTL10040 TARC1 0403 ICRXPTC ICRXATC ICTXPTC ICTXATC ICTXQEC ICTXQMTC ICRXDMTC ICRXOC RXCSUM
Re: 2.6.24-mm1 bugs
Miklos Szeredi wrote: >>> - network doesn't always come up at first try (e1000e). On 2.6.24 >>>e1000e doesn't seem to work at all, so I use e1000, but that has >>>other problems. > > It does seem to be using MSI interrupts: > >CPU0 CPU1 > 0:2994380 1 IO-APIC-edge timer > 1: 24 0 IO-APIC-edge i8042 > 8: 1 0 IO-APIC-edge rtc > 9: 2107 0 IO-APIC-fasteoi acpi > 12: 3570 0 IO-APIC-edge i8042 > 14: 92 0 IO-APIC-edge ide0 > 16: 124168 0 IO-APIC-fasteoi uhci_hcd:usb2 > 17: 287458 0 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel > 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 > 19: 70 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5 > 313: 75321 5 PCI-MSI-edge eth0 OK. can you download, install and run `ethregs -i eth0` (from e1000.sf.net) and send me the output? I'll compare with a known working t60 I have here and see if anything shows up. Also, post me the dmesg from after the adapter fails to load properly. thanks, Auke -- 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/
isofs - Re: 2.6.24-mm1 bugs
On Fri, 15 Feb 2008 12:43:45 +0100, Miklos Szeredi said: > I'm trying out 2.6.24-mm1 on my work laptop (T60), and generally it > - mounting isofs always results in an empty directory I hit this in 24-rc8-mm1, and bisected it down to iget-stop-isofs-from-using-read_inode-fix-2.patch Apparently it got broken way back in 24-rc6-mm1. And that directory is *really* empty - even . and .. are missing. :) pgpMCRyqCMqrQ.pgp Description: PGP signature
Re: 2.6.24-mm1 bugs
Kok, Auke wrote: > Miklos Szeredi wrote: >> - network doesn't always come up at first try (e1000e). On 2.6.24 >>e1000e doesn't seem to work at all, so I use e1000, but that has >>other problems. > > Andy Gospodarek pointed out a possible problem with e1000e if you are not > using > MSI interrupts (e.g. booting with pci=nomsi or CONFIG_PCI_MSI=n). Can you > confirm > that you are not using MSI irqs? If so, then we have a patch that you can try. oops, I'm confusing things here, ignore that > IOW post your `cat /proc/interrupts` please :) please send this, as well as full dmesg and anything that you can think of might be important. Auke -- 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.24-mm1 bugs
> > - network doesn't always come up at first try (e1000e). On 2.6.24 > >e1000e doesn't seem to work at all, so I use e1000, but that has > >other problems. > > Andy Gospodarek pointed out a possible problem with e1000e if you > are not using MSI interrupts (e.g. booting with pci=nomsi or > CONFIG_PCI_MSI=n). Can you confirm that you are not using MSI irqs? > If so, then we have a patch that you can try. > > IOW post your `cat /proc/interrupts` please :) It does seem to be using MSI interrupts: CPU0 CPU1 0:2994380 1 IO-APIC-edge timer 1: 24 0 IO-APIC-edge i8042 8: 1 0 IO-APIC-edge rtc 9: 2107 0 IO-APIC-fasteoi acpi 12: 3570 0 IO-APIC-edge i8042 14: 92 0 IO-APIC-edge ide0 16: 124168 0 IO-APIC-fasteoi uhci_hcd:usb2 17: 287458 0 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 19: 70 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5 313: 75321 5 PCI-MSI-edge eth0 314: 51727 0 PCI-MSI-edge ahci NMI: 0 0 Non-maskable interrupts LOC: 2210391784533 Local timer interrupts RES: 478115 572161 Rescheduling interrupts CAL:216191 function call interrupts TLB: 1943 1176 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts SPU: 0 0 Spurious interrupts ERR: 0 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-mm1 # Fri Feb 15 16:25:45 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_QUICKLIST is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_X86_TRAMPOLINE=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set # CONFIG_FAIR_GROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP
Re: 2.6.24-mm1 bugs
Miklos Szeredi wrote: > - network doesn't always come up at first try (e1000e). On 2.6.24 >e1000e doesn't seem to work at all, so I use e1000, but that has >other problems. Andy Gospodarek pointed out a possible problem with e1000e if you are not using MSI interrupts (e.g. booting with pci=nomsi or CONFIG_PCI_MSI=n). Can you confirm that you are not using MSI irqs? If so, then we have a patch that you can try. IOW post your `cat /proc/interrupts` please :) Auke -- 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.24-mm1 bugs
> On Fri, 2008-02-15 at 12:43 +0100, Miklos Szeredi wrote: > > > - strange key repeating (short press of a key results in lots of key > >press events) when there's some sort of load (I/O?) I may have > >seen this on non-mm kernels as well, but it's definitely more > >noticable in -mm > > Do you have CONFIG_FAIR_GROUP_SCHED enabled?, if so, does disabling it > make it go away? Yes, it's enabled. I'll try disabling, but can't immediately verify if it's fixed, as this happens relatively rarely. But to me it doesn't really sound like a scheduling issue. Rather something timer or interrupt related. But I'm very stupid in all these areas, so... Thanks, Miklos -- 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.24-mm1 bugs
On Fri, 2008-02-15 at 12:43 +0100, Miklos Szeredi wrote: > - strange key repeating (short press of a key results in lots of key >press events) when there's some sort of load (I/O?) I may have >seen this on non-mm kernels as well, but it's definitely more >noticable in -mm Do you have CONFIG_FAIR_GROUP_SCHED enabled?, if so, does disabling it make it go away? -- 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.24-mm1 bugs
I'm trying out 2.6.24-mm1 on my work laptop (T60), and generally it works surprisingly well (including suspend/resume), with only a few minor issues. If these are not known/fixed already, I'll send out proper bug reports to the relevant people: - UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any other. Same guest boots fine on 2.6.24 host. - mounting isofs always results in an empty directory - network doesn't always come up at first try (e1000e). On 2.6.24 e1000e doesn't seem to work at all, so I use e1000, but that has other problems. - strange key repeating (short press of a key results in lots of key press events) when there's some sort of load (I/O?) I may have seen this on non-mm kernels as well, but it's definitely more noticable in -mm Thanks, Miklos -- 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.24-mm1 bugs
I'm trying out 2.6.24-mm1 on my work laptop (T60), and generally it works surprisingly well (including suspend/resume), with only a few minor issues. If these are not known/fixed already, I'll send out proper bug reports to the relevant people: - UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any other. Same guest boots fine on 2.6.24 host. - mounting isofs always results in an empty directory - network doesn't always come up at first try (e1000e). On 2.6.24 e1000e doesn't seem to work at all, so I use e1000, but that has other problems. - strange key repeating (short press of a key results in lots of key press events) when there's some sort of load (I/O?) I may have seen this on non-mm kernels as well, but it's definitely more noticable in -mm Thanks, Miklos -- 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.24-mm1 bugs
On Fri, 2008-02-15 at 12:43 +0100, Miklos Szeredi wrote: - strange key repeating (short press of a key results in lots of key press events) when there's some sort of load (I/O?) I may have seen this on non-mm kernels as well, but it's definitely more noticable in -mm Do you have CONFIG_FAIR_GROUP_SCHED enabled?, if so, does disabling it make it go away? Yes, it's enabled. I'll try disabling, but can't immediately verify if it's fixed, as this happens relatively rarely. But to me it doesn't really sound like a scheduling issue. Rather something timer or interrupt related. But I'm very stupid in all these areas, so... Thanks, Miklos -- 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.24-mm1 bugs
On Fri, 2008-02-15 at 12:43 +0100, Miklos Szeredi wrote: - strange key repeating (short press of a key results in lots of key press events) when there's some sort of load (I/O?) I may have seen this on non-mm kernels as well, but it's definitely more noticable in -mm Do you have CONFIG_FAIR_GROUP_SCHED enabled?, if so, does disabling it make it go away? -- 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.24-mm1 bugs
Miklos Szeredi wrote: - network doesn't always come up at first try (e1000e). On 2.6.24 e1000e doesn't seem to work at all, so I use e1000, but that has other problems. Andy Gospodarek pointed out a possible problem with e1000e if you are not using MSI interrupts (e.g. booting with pci=nomsi or CONFIG_PCI_MSI=n). Can you confirm that you are not using MSI irqs? If so, then we have a patch that you can try. IOW post your `cat /proc/interrupts` please :) Auke -- 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.24-mm1 bugs
- network doesn't always come up at first try (e1000e). On 2.6.24 e1000e doesn't seem to work at all, so I use e1000, but that has other problems. Andy Gospodarek pointed out a possible problem with e1000e if you are not using MSI interrupts (e.g. booting with pci=nomsi or CONFIG_PCI_MSI=n). Can you confirm that you are not using MSI irqs? If so, then we have a patch that you can try. IOW post your `cat /proc/interrupts` please :) It does seem to be using MSI interrupts: CPU0 CPU1 0:2994380 1 IO-APIC-edge timer 1: 24 0 IO-APIC-edge i8042 8: 1 0 IO-APIC-edge rtc 9: 2107 0 IO-APIC-fasteoi acpi 12: 3570 0 IO-APIC-edge i8042 14: 92 0 IO-APIC-edge ide0 16: 124168 0 IO-APIC-fasteoi uhci_hcd:usb2 17: 287458 0 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 19: 70 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5 313: 75321 5 PCI-MSI-edge eth0 314: 51727 0 PCI-MSI-edge ahci NMI: 0 0 Non-maskable interrupts LOC: 2210391784533 Local timer interrupts RES: 478115 572161 Rescheduling interrupts CAL:216191 function call interrupts TLB: 1943 1176 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts SPU: 0 0 Spurious interrupts ERR: 0 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-mm1 # Fri Feb 15 16:25:45 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_QUICKLIST is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_X86_TRAMPOLINE=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set # CONFIG_FAIR_GROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set
Re: 2.6.24-mm1 bugs
Kok, Auke wrote: Miklos Szeredi wrote: - network doesn't always come up at first try (e1000e). On 2.6.24 e1000e doesn't seem to work at all, so I use e1000, but that has other problems. Andy Gospodarek pointed out a possible problem with e1000e if you are not using MSI interrupts (e.g. booting with pci=nomsi or CONFIG_PCI_MSI=n). Can you confirm that you are not using MSI irqs? If so, then we have a patch that you can try. oops, I'm confusing things here, ignore that IOW post your `cat /proc/interrupts` please :) please send this, as well as full dmesg and anything that you can think of might be important. Auke -- 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.24-mm1 bugs
OK. can you download, install and run `ethregs -i eth0` (from e1000.sf.net) and send me the output? I'll compare with a known working t60 I have here and see if anything shows up. OK, attached. Also, post me the dmesg from after the adapter fails to load properly. Hmm, nothing in dmesg. Looking at syslog, I'm not even sure it's a driver issue, it could also be dhclient or NetworkManager bug. The strange thing is that this only happens on -mm. These are the relevant syslog messages for an unsuccessful attempt: == Feb 15 12:27:32 tucsk kernel: [ 35.169183] :02:00.0: eth0: Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX Feb 15 12:27:32 tucsk kernel: [ 35.169190] :02:00.0: eth0: 10/100 speed: disabling TSO Feb 15 12:27:40 tucsk dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 Feb 15 12:27:40 tucsk dhclient: DHCPOFFER from 192.168.0.1 Feb 15 12:27:45 tucsk dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Feb 15 12:27:45 tucsk dhclient: DHCPACK from 192.168.0.1 Feb 15 12:27:46 tucsk dhclient: bound to 192.168.0.9 -- renewal in 1539 seconds. Feb 15 12:28:20 tucsk dhclient: caught deadly SIGTERM Feb 15 12:28:20 tucsk dhclient: could not restore resolv.conf: No such file or directory Feb 15 12:28:20 tucsk dhclient: DHCPRELEASE on eth0 to 192.168.0.1 port 67 Feb 15 12:28:20 tucsk dhclient: send_packet: Network is unreachable Feb 15 12:28:20 tucsk dhclient: send_packet: please consult README file regarding broadcast address. == And then for the successful one: == Feb 15 12:29:17 tucsk dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 2 Feb 15 12:29:17 tucsk dhclient: DHCPOFFER from 192.168.0.1 Feb 15 12:29:22 tucsk dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Feb 15 12:29:22 tucsk dhclient: DHCPACK from 192.168.0.1 Feb 15 12:29:22 tucsk dhclient: bound to 192.168.0.9 -- renewal in 1543 seconds. == Thanks, Miklos 02:00.0 (8086:109a) Unknown device 8086:109a Name Value ~ CTRL 18140248 STATUS 80080743 EECD 06008318 EERD 00510016 CTRL_EXT 2878 FLA0600 MDIC 18316d4c FCAL 00c28001 FCAH 0100 FCT8808 VET8100 ITR03d0 ICS IMS009d IMC009d IAM RCTL 8002 FCTTV 0680 TCTL 3103f0fa TIPG 00602008 AIT LEDCTL 000f8b02 EXTCNF_CTRL0014000a EXTCNF_SIZE0004 PBA000c0014 PBS0020 EEMNGCTL 8000 EEARBC 001d0290 FLASHT 0002 EEWR 0002 FLSWCTLc000 FLSWDATA FLSWCNT FLOP 0004db00 ERT FCRTL 800047f8 FCRTH 4800 PSRCTL 00040402 RDBAL 22346000 RDBAH RDLEN 1000 RDH00ee RDT00ec RDTR RXDCTL 0001 RADV 0008 RDBAL1 0410 RDBAH1 1200 RDLEN1 RDH1 RDT1 RSRPD RAID CPUVEC TDFH 0d00 TDFT 0d00 TDFHS 0d00 TDFTS 0d00 TDFPC TDBAL 3cc46000 TDBAH TDLEN 1000 TDH0002 TDT0002 TIDV 0008 TXDCTL 0141 TADV 0020 TARC0 0403 TDBAL1 9840 TDBAH1 12002000 TDLEN1 TDH1 TDT1 TXDCTL10040 TARC1 0403 ICRXPTC ICRXATC ICTXPTC ICTXATC ICTXQEC ICTXQMTC ICRXDMTC ICRXOC RXCSUM
Re: 2.6.24-mm1 bugs
the register dump looks OK as far as I can see. Since initialization works OK and the adapter seems to be setup OK reading from the register dump, I'm not sure at all what is going on. can you try manually ifup-ing the device and running tcpdump? do you see packets coming in? Well it does seem to receive the DHCP reply. just for kicks, have you tried a different cable? or is the adapter consistently working properly using a different kernel/driver? It has been consistently working properly for a long time with various kernels (and the e1000 driver). I've now swithed to 2.6.24-mm1 and e1000e, and it's almost consistently broken after boot and resume, and sometimes needs several tries (with the KDE NetworkManager thingy) to make it work. My guess is that either NetworkManager is buggy, or there's something else in -mm that's breaking NetworkManager. But now it does seem unlikely to be an ethernet driver issue. Thanks, Miklos -- 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.24-mm1 bugs
Miklos Szeredi wrote: the register dump looks OK as far as I can see. Since initialization works OK and the adapter seems to be setup OK reading from the register dump, I'm not sure at all what is going on. can you try manually ifup-ing the device and running tcpdump? do you see packets coming in? Well it does seem to receive the DHCP reply. just for kicks, have you tried a different cable? or is the adapter consistently working properly using a different kernel/driver? It has been consistently working properly for a long time with various kernels (and the e1000 driver). I've now swithed to 2.6.24-mm1 and e1000e, and it's almost consistently broken after boot and resume, and sometimes needs several tries (with the KDE NetworkManager thingy) to make it work. maybe it's worth trying linux-2.6.git instead for now? The e1000e driver is actually involved in the dhcp handshake so we can't just rule a bug out yet. However, with my own t60 things appear to work just fine. how does manually getting a dhcp address go? can you eliminate networkmanager perhaps? just kill restart dhclient over and over again... Auke -- 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.24-mm1 bugs
Miklos Szeredi wrote:
OK. can you download, install and run `ethregs -i eth0` (from
e1000.sf.net) and send me the output? I'll compare with a known
working t60 I have here and see if anything shows up.
OK, attached.
Also, post me the dmesg from after the adapter fails to load
properly.
Hmm, nothing in dmesg. Looking at syslog, I'm not even sure it's a
driver issue, it could also be dhclient or NetworkManager bug. The
strange thing is that this only happens on -mm.
These are the relevant syslog messages for an unsuccessful attempt:
==
Feb 15 12:27:32 tucsk kernel: [ 35.169183] :02:00.0: eth0: Link is Up
100 Mbps Full Duplex, Flow Control: RX/TX
Feb 15 12:27:32 tucsk kernel: [ 35.169190] :02:00.0: eth0: 10/100
speed: disabling TSO
Feb 15 12:27:40 tucsk dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port
67 interval 4
Feb 15 12:27:40 tucsk dhclient: DHCPOFFER from 192.168.0.1
Feb 15 12:27:45 tucsk dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Feb 15 12:27:45 tucsk dhclient: DHCPACK from 192.168.0.1
Feb 15 12:27:46 tucsk dhclient: bound to 192.168.0.9 -- renewal in 1539
seconds.
Feb 15 12:28:20 tucsk dhclient: caught deadly SIGTERM
Feb 15 12:28:20 tucsk dhclient: could not restore resolv.conf: No such file
or directory
Feb 15 12:28:20 tucsk dhclient: DHCPRELEASE on eth0 to 192.168.0.1 port 67
Feb 15 12:28:20 tucsk dhclient: send_packet: Network is unreachable
Feb 15 12:28:20 tucsk dhclient: send_packet: please consult README file
regarding broadcast address.
==
And then for the successful one:
==
Feb 15 12:29:17 tucsk dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port
67 interval 2
Feb 15 12:29:17 tucsk dhclient: DHCPOFFER from 192.168.0.1
Feb 15 12:29:22 tucsk dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Feb 15 12:29:22 tucsk dhclient: DHCPACK from 192.168.0.1
Feb 15 12:29:22 tucsk dhclient: bound to 192.168.0.9 -- renewal in 1543
seconds.
==
Thanks,
Miklos
02:00.0 (8086:109a)
Unknown device 8086:109a
Name Value
~
CTRL 18140248
the register dump looks OK as far as I can see. Since initialization works OK
and
the adapter seems to be setup OK reading from the register dump, I'm not sure at
all what is going on.
can you try manually ifup-ing the device and running tcpdump? do you see packets
coming in?
just for kicks, have you tried a different cable? or is the adapter consistently
working properly using a different kernel/driver?
Auke
--
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.24-mm1 bugs
And here's the NetworkManager side of the log: == Feb 15 12:27:30 tucsk NetworkManager: info starting... Feb 15 12:27:30 tucsk NetworkManager: debug [1203074850.429242] nm_system_device_get_system_config(): found config '/etc/sysconfig/network/ifcfg-eth0' for interface 'eth0' Feb 15 12:27:30 tucsk NetworkManager: debug [1203074850.429334] nm_system_device_get_system_config(): BOOTPROTO=dhcp Feb 15 12:27:30 tucsk NetworkManager: debug [1203074850.429373] nm_system_device_get_system_config(): -- Config (eth0) Feb 15 12:27:30 tucsk NetworkManager: debug [1203074850.429392] nm_system_device_get_system_config(): dhcp=1 Feb 15 12:27:30 tucsk NetworkManager: debug [1203074850.429423] nm_system_device_get_system_config(): addr=0.0.0.0 Feb 15 12:27:30 tucsk NetworkManager: debug [1203074850.429441] nm_system_device_get_system_config(): gw=0.0.0.0 Feb 15 12:27:30 tucsk NetworkManager: debug [1203074850.429458] nm_system_device_get_system_config(): mask=0.0.0.0 Feb 15 12:27:30 tucsk NetworkManager: debug [1203074850.429476] nm_system_device_get_system_config(): - Feb 15 12:27:30 tucsk NetworkManager: info eth0: Device is fully-supported using driver 'e1000e'. Feb 15 12:27:30 tucsk NetworkManager: info nm_device_init(): waiting for device's worker thread to start Feb 15 12:27:30 tucsk NetworkManager: info nm_device_init(): device's worker thread started, continuing. Feb 15 12:27:30 tucsk NetworkManager: info Now managing wired Ethernet (802.3) device 'eth0'. Feb 15 12:27:30 tucsk NetworkManager: info Deactivating device eth0. Feb 15 12:27:32 tucsk NetworkManager: info Will activate wired connection 'eth0' because it now has a link. Feb 15 12:27:32 tucsk NetworkManager: info SWITCH: no current connection, found better connection 'eth0'. Feb 15 12:27:33 tucsk NetworkManager: info Will activate connection 'eth0'. Feb 15 12:27:33 tucsk NetworkManager: info Device eth0 activation scheduled... Feb 15 12:27:33 tucsk NetworkManager: info Activation (eth0) started... Feb 15 12:27:33 tucsk NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... Feb 15 12:27:33 tucsk NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) started... Feb 15 12:27:33 tucsk NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... Feb 15 12:27:33 tucsk NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) complete. Feb 15 12:27:33 tucsk NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) starting... Feb 15 12:27:33 tucsk NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) successful. Feb 15 12:27:33 tucsk NetworkManager: info Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled. Feb 15 12:27:33 tucsk NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) complete. Feb 15 12:27:33 tucsk NetworkManager: info Activation (eth0) Stage 3 of 5 (IP Configure Start) started... Feb 15 12:27:35 tucsk NetworkManager: info Activation (eth0) Beginning DHCP transaction. Feb 15 12:27:35 tucsk NetworkManager: info Activation (eth0) Stage 3 of 5 (IP Configure Start) complete. Feb 15 12:27:35 tucsk NetworkManager: info DHCP daemon state is now 12 (successfully started) for interface eth0 Feb 15 12:28:07 tucsk NetworkManager: info Updating allowed wireless network lists. Feb 15 12:28:10 tucsk NetworkManager: info Old device 'eth0' activating, won't change. Feb 15 12:28:20 tucsk NetworkManager: info Device 'eth0' DHCP transaction took too long (45s), stopping it. Feb 15 12:28:21 tucsk NetworkManager: info Activation (eth0) Stage 4 of 5 (IP Configure Timeout) scheduled... Feb 15 12:28:21 tucsk NetworkManager: info Activation (eth0) Stage 4 of 5 (IP Configure Timeout) started... Feb 15 12:28:21 tucsk NetworkManager: info No DHCP reply received. Automatically obtaining IP via Zeroconf. == So it does indeed look like some communication problem between NetworkManager and dhclient, as NetworkManager thinks there was no DHCP reply when in fac there was one: == Feb 15 12:27:32 tucsk kernel: [ 35.169183] :02:00.0: eth0: Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX Feb 15 12:27:32 tucsk kernel: [ 35.169190] :02:00.0: eth0: 10/100 speed: disabling TSO Feb 15 12:27:40 tucsk dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 Feb 15 12:27:40 tucsk dhclient: DHCPOFFER from 192.168.0.1 Feb 15 12:27:45 tucsk dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Feb 15 12:27:45 tucsk dhclient: DHCPACK from 192.168.0.1 Feb 15 12:27:46 tucsk dhclient: bound to 192.168.0.9 -- renewal in 1539 seconds. Feb 15 12:28:20 tucsk dhclient: caught deadly SIGTERM Feb 15 12:28:20 tucsk dhclient: could not restore
Re: 2.6.24-mm1 bugs
On Fri, Feb 15, 2008 at 12:43:45PM +0100, Miklos Szeredi wrote: - UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any other. Same guest boots fine on 2.6.24 host. What does it do? Any chance you can bisect it? Jeff -- Work email - jdike at linux dot intel dot com -- 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.24-mm1 bugs
- UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any other. Same guest boots fine on 2.6.24 host. What does it do? See below. Any chance you can bisect it? It would be a bit painful, because this is the only machine I can use. I much prefer bisecting UML kernels :) Thanks, Miklos GNU gdb 6.6.50.20070726-cvs Copyright (C) 2007 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-suse-linux... Using host libthread_db library /lib64/libthread_db.so.1. (gdb) r umid=uml Starting program: /store/quilt/linux/linux umid=uml Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...missing Checking for tmpfs mount on /dev/shm...nothing mounted on /dev/shm Checking PROT_EXEC mmap in /tmp/...OK Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO...not found: Invalid argument - PTRACE_LDT...not found: Invalid argument UML running in SKAS0 mode Adding 24977408 bytes to physical memory to account for exec-shield gap [0.00] Linux version 2.6.24-mm1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (SUSE Linux)) #26 Fri Feb 15 11:05:54 CET 2008 [0.01] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 14179 [0.01] Kernel command line: root=98:0 [0.01] PID hash table entries: 256 (order: 8, 1024 bytes) [0.01] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [0.01] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [0.01] Memory: 29504k available [0.27] Mount-cache hash table entries: 512 [0.27] Checking for host processor cmov support...Yes [0.27] Checking that host ptys support output SIGIO...Yes [0.27] Checking that host ptys support SIGIO on close...No, enabling workaround [0.27] net_namespace: 184 bytes [0.27] Using 2.6 host AIO [0.27] NET: Registered protocol family 16 [0.30] NET: Registered protocol family 2 [0.31] Time: itimer clocksource has been installed. [0.39] IP route cache hash table entries: 1024 (order: 0, 4096 bytes) [0.39] TCP established hash table entries: 2048 (order: 2, 16384 bytes) [0.39] TCP bind hash table entries: 2048 (order: 3, 40960 bytes) [0.39] TCP: Hash tables configured (established 2048 bind 2048) [0.39] TCP reno registered [0.42] Checking host MADV_REMOVE support...3MADV_REMOVE failed, err = -38 [0.42] Can't release memory to the host - memory hotplug won't be supported [0.42] mconsole (version 2) initialized on /home/mszeredi/.uml/uml/mconsole [0.42] Host TLS support detected [0.42] Detected host type: x86_64 (GDT indexes 12 to 15) [0.42] fuse init (API version 7.9) [0.42] io scheduler noop registered (default) [0.42] loop: module loaded [0.42] TCP cubic registered [0.42] NET: Registered protocol family 1 [0.42] Initialized stdio console driver [0.42] Console initialized on /dev/tty0 [0.42] console [tty0] enabled [0.42] console [mc-1] enabled [0.42] ubda: unknown partition table [0.42] kjournald starting. Commit interval 5 seconds [0.42] EXT3-fs: mounted filesystem with ordered data mode. [0.42] VFS: Mounted root (ext3 filesystem) readonly. [0.42] Failed to get registers from stub, errno = 3 [0.42] wait_stub_done : failed to wait for SIGTRAP, pid = 30073, n = 30073, errno = 0, status = 0x0 [New LWP 30070] [New LWP 30071] [New LWP 30072] Program received signal SIGTERM, Terminated. 0xe430 in __kernel_vsyscall () (gdb) bt #0 0xe430 in __kernel_vsyscall () #1 0xf7eabc26 in kill () from /lib/libc.so.6 #2 0x0806cf82 in os_dump_core () at arch/um/os-Linux/util.c:105 #3 0x0805d64d in fatal_sigsegv () at arch/um/kernel/trap.c:141 #4 0x0806e32b in wait_stub_done (pid=30073) at arch/um/os-Linux/skas/process.c:94 #5 0x0806d94b in run_syscall_stub (mm_idp=0xb26ff18, syscall=123, args=0xb067e08, expected=0, addr=0xb067ea4, done=1) at arch/um/os-Linux/skas/mem.c:86 #6 0x0806f997 in write_ldt_entry (mm_idp=0xb26ff18, func=1, desc=0xb067e94, addr=0xb067ea4, done=1) at arch/um/sys-i386/ldt.c:72 #7 0x08070434 in init_new_ldt (new_mm=0xb26ff18, from_mm=0x0) at arch/um/sys-i386/ldt.c:425 #8 0x0805de43 in init_new_context (task=0xb05bc00, mm=0xb26fdc0) at arch/um/kernel/skas/mmu.c:87 #9 0x080ce3c1 in bprm_mm_init (bprm=0xb1a6980) at fs/exec.c:337 #10 0x080cfa2d in do_execve
isofs - Re: 2.6.24-mm1 bugs
On Fri, 15 Feb 2008 12:43:45 +0100, Miklos Szeredi said: I'm trying out 2.6.24-mm1 on my work laptop (T60), and generally it - mounting isofs always results in an empty directory I hit this in 24-rc8-mm1, and bisected it down to iget-stop-isofs-from-using-read_inode-fix-2.patch Apparently it got broken way back in 24-rc6-mm1. And that directory is *really* empty - even . and .. are missing. :) pgpMCRyqCMqrQ.pgp Description: PGP signature
Re: 2.6.24-mm1 bugs
Miklos Szeredi wrote: - network doesn't always come up at first try (e1000e). On 2.6.24 e1000e doesn't seem to work at all, so I use e1000, but that has other problems. It does seem to be using MSI interrupts: CPU0 CPU1 0:2994380 1 IO-APIC-edge timer 1: 24 0 IO-APIC-edge i8042 8: 1 0 IO-APIC-edge rtc 9: 2107 0 IO-APIC-fasteoi acpi 12: 3570 0 IO-APIC-edge i8042 14: 92 0 IO-APIC-edge ide0 16: 124168 0 IO-APIC-fasteoi uhci_hcd:usb2 17: 287458 0 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 19: 70 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5 313: 75321 5 PCI-MSI-edge eth0 OK. can you download, install and run `ethregs -i eth0` (from e1000.sf.net) and send me the output? I'll compare with a known working t60 I have here and see if anything shows up. Also, post me the dmesg from after the adapter fails to load properly. thanks, Auke -- 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.24-mm1 bugs
On Fri, Feb 15, 2008 at 08:52:04PM +0100, Miklos Szeredi wrote: What does it do? See below. [0.42] Checking host MADV_REMOVE support...3MADV_REMOVE failed, err = -38 Where'd MADV_REMOVE go? I have it on 2.6.24. Oh, I always get this message. Looking closer, this only works if /tmp is tmpfs. Which isn't in most cases. [0.42] Failed to get registers from stub, errno = 3 [0.42] wait_stub_done : failed to wait for SIGTRAP, pid = 30073, n = 30073, errno = 0, status = 0x0 Is utrace in there, by any chance? When I see crazy stuff like this, I think utrace. Nope. Must be some other crazy stuff :) Miklos -- 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.24-mm1 bugs
On Fri, Feb 15, 2008 at 08:52:04PM +0100, Miklos Szeredi wrote: What does it do? See below. [0.42] Checking host MADV_REMOVE support...3MADV_REMOVE failed, err = -38 Where'd MADV_REMOVE go? I have it on 2.6.24. [0.42] Failed to get registers from stub, errno = 3 [0.42] wait_stub_done : failed to wait for SIGTRAP, pid = 30073, n = 30073, errno = 0, status = 0x0 Is utrace in there, by any chance? When I see crazy stuff like this, I think utrace. Jeff -- Work email - jdike at linux dot intel dot com -- 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: isofs - Re: 2.6.24-mm1 bugs
On Fri, 15 Feb 2008 11:46:55 -0500
[EMAIL PROTECTED] wrote:
On Fri, 15 Feb 2008 12:43:45 +0100, Miklos Szeredi said:
I'm trying out 2.6.24-mm1 on my work laptop (T60), and generally it
- mounting isofs always results in an empty directory
I hit this in 24-rc8-mm1, and bisected it down to
iget-stop-isofs-from-using-read_inode-fix-2.patch
Apparently it got broken way back in 24-rc6-mm1.
And that directory is *really* empty - even . and .. are missing. :)
Seems that 2.6.24-mm1+hot-fixes still didn't have
iget-stop-isofs-from-using-read_inode-fix-3.patch:
From: David Howells [EMAIL PROTECTED]
Fix isofs_get_block() to return only 0 on success. It shouldn't return a
+ve block count for example.
Also make sure that isofs_get_blocks() doesn't accidentally return an error
if rv is 0 come the return statement.
Signed-off-by: David Howells [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
fs/isofs/inode.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff -puN fs/isofs/inode.c~iget-stop-isofs-from-using-read_inode-fix-3
fs/isofs/inode.c
--- a/fs/isofs/inode.c~iget-stop-isofs-from-using-read_inode-fix-3
+++ a/fs/isofs/inode.c
@@ -1022,6 +1022,7 @@ int isofs_get_blocks(struct inode *inode
rv++;
}
+ error = 0;
abort:
unlock_kernel();
return rv != 0 ? rv : error;
@@ -1033,12 +1034,15 @@ abort:
static int isofs_get_block(struct inode *inode, sector_t iblock,
struct buffer_head *bh_result, int create)
{
+ int ret;
+
if (create) {
printk(KERN_DEBUG %s: Kernel tries to allocate a block\n,
__func__);
return -EROFS;
}
- return isofs_get_blocks(inode, iblock, bh_result, 1);
+ ret = isofs_get_blocks(inode, iblock, bh_result, 1);
+ return ret 0 ? ret : 0;
}
static int isofs_bmap(struct inode *inode, sector_t block)
_
--
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.24-mm1 bugs
On Friday 15 February 2008, Miklos Szeredi wrote: - UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any other. Same guest boots fine on 2.6.24 host. What does it do? See below. Any chance you can bisect it? It would be a bit painful, because this is the only machine I can use. I much prefer bisecting UML kernels :) Is it possible to bisect uml kernels inside qemu? :) Thanks, Bart -- 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/
