Re: FUTEX deadlock in ping?
Olof Johansson wrote: On Thu, Feb 24, 2005 at 11:14:45AM +0100, Jörn Nettingsmeier wrote: futex(0x401540f4, FUTEX_WAIT, 2, NULL ^^ is this one related to the FUTEX problem olof described? As bert said, it's likely something else. Is the process killable, and does "ps aux" complete? yes and yes. If so, then this is a different problem. too bad. i thought i had finally found a clue.. sorry for the noise, and many thanks for explaining! - 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/
FUTEX deadlock in ping?
hi !
disclaimer: i'm not a kernel guy ;)
after reading the FUTEX deadlock thread
(http://thread.gmane.org/gmane.linux.kernel/280900), i was wondering:
ever since moving to ldap for passwd/group/shadow/hosts lookup, ping to
a non-reachable host just freezes up and never returns:
spunk:~ # strace ping herrnilsson
execve("/bin/ping", ["ping", "herrnilsson"], [/* 61 vars */]) = 0
uname({sys="Linux", node="spunk", ...}) = 0
brk(0) = 0x8063000
...
...
munmap(0x40504000, 4096)= 0
brk(0x80a5000) = 0x80a5000
uname({sys="Linux", node="spunk", ...}) = 0
futex(0x401540f4, FUTEX_WAIT, 2, NULL
^^
is this one related to the FUTEX problem olof described?
best,
jörn
ps: i'd appreciate being cc:ed on replies. thanks.
for the record:
spunk:~ # uname -a
Linux spunk 2.6.8-24.11-smp #1 SMP Fri Jan 14 13:01:26 UTC 2005 i686
i686 i386 GNU/Linux
SuSE 9.2
problem happens also on ia32 UP (same version as before) and amd64 UP
(2.6.11-rc4-bk7)
ldap lookup is ok, for instance
spunk:~ # getent hosts herrnilsson
192.168.0.3 herrnilsson.villakunterbunt.netz herrnilsson
traceroute and others work as well.
on an otherwise identical system without ldap, ping correctly gives
"unreachable" messages.
-
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/
FUTEX deadlock in ping?
hi !
disclaimer: i'm not a kernel guy ;)
after reading the FUTEX deadlock thread
(http://thread.gmane.org/gmane.linux.kernel/280900), i was wondering:
ever since moving to ldap for passwd/group/shadow/hosts lookup, ping to
a non-reachable host just freezes up and never returns:
spunk:~ # strace ping herrnilsson
execve(/bin/ping, [ping, herrnilsson], [/* 61 vars */]) = 0
uname({sys=Linux, node=spunk, ...}) = 0
brk(0) = 0x8063000
...
...
munmap(0x40504000, 4096)= 0
brk(0x80a5000) = 0x80a5000
uname({sys=Linux, node=spunk, ...}) = 0
futex(0x401540f4, FUTEX_WAIT, 2, NULL
^^
is this one related to the FUTEX problem olof described?
best,
jörn
ps: i'd appreciate being cc:ed on replies. thanks.
for the record:
spunk:~ # uname -a
Linux spunk 2.6.8-24.11-smp #1 SMP Fri Jan 14 13:01:26 UTC 2005 i686
i686 i386 GNU/Linux
SuSE 9.2
problem happens also on ia32 UP (same version as before) and amd64 UP
(2.6.11-rc4-bk7)
ldap lookup is ok, for instance
spunk:~ # getent hosts herrnilsson
192.168.0.3 herrnilsson.villakunterbunt.netz herrnilsson
traceroute and others work as well.
on an otherwise identical system without ldap, ping correctly gives
unreachable messages.
-
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: FUTEX deadlock in ping?
Olof Johansson wrote: On Thu, Feb 24, 2005 at 11:14:45AM +0100, Jörn Nettingsmeier wrote: futex(0x401540f4, FUTEX_WAIT, 2, NULL ^^ is this one related to the FUTEX problem olof described? As bert said, it's likely something else. Is the process killable, and does ps aux complete? yes and yes. If so, then this is a different problem. too bad. i thought i had finally found a clue.. sorry for the noise, and many thanks for explaining! - 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: kernel lockup in 2.4.5-ac3 and 2.4.6-pre7 (netfilter ?)
just fyi, 2.4.7-pre8 did not cure the problem. i was able to reproduce the problem like before. this time, i switched to the log console before locking the machine up, and the oops is in fact identical to the one christian was seeing. the last line says "In interrupt handler - not syncing." which seems to explain why no syslog messages survive. regards, jörn -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: kernel lockup in 2.4.5-ac3 and 2.4.6-pre7 (netfilter ?)
[christian, i'm quoting a message of yours below. maybe this is of interest to you, so i'm cc:ing] Thomas wrote: > > Jörn Nettingsmeier wrote: > > > hello brad, hello netfilter people ! > > Brad Chapman wrote: > > > >>Were you able to rescue any console output from the hard > >> lockup; > >> i.e. you did a klogd -c 7 to capture _everything_ the kernel > >> spit out? > >> If you were able to, could you send them to the list, please? > >> > > i have just reproduced the lockup with the klogd setting you > > suggested, but no entries at all have survived. > > however, it has been pointed out to me that my lockups might be > > caused by a faulty pppoe module (i'm using a dsl connection) > > rather > > than netfilter. > > it looks like i need to investigate a little further on pppoe... > > let's see what the lkml archive has to say. > > thanks for all the helpful replies. i will keep you posted if i > > can > > solve this problem. > > > Hi, > i can't help you exactly, but i also use T-Dsl and also there it > come to hangup's ( sometimes kernel panic ) > At the moment i get it off, i switched the debug mode on and log > all the crap in an file ( hoped i find the error ) > but after debug on there was no more hangup. I'm sure it is an bug > in the pppoe system, wich come to work > when the T* have trouble and send defekt packets. The ground i > think it have to do with defekt packets is > that other frinds with dsl under windoff told me that they also > have on the same time many disconnects. > > Cu thomas i found someone else's oops report on lkml, and this is exactly the one i'm seeing, although i can't save it for lack of a serial console: > christian wrote on lkml: > > PROBLEM: Kernel Panics since i switched to T-DSL, using > masquadering. Supposed to be > fixed in 2.4.5pre9 ? > > virtual address 8ba7 > *pde = > Oops = > CPU = 0 > EIP = 0010:[] > EFLAGS: 00010202 > > eax: c1569940 ebx: 8ba7 ecx: edx: 00068ba7 > esi: c1b5ce80 edi: c15697e0 ebp: 0060 esp: c0e41dd4 > ds: 0018 es: 0018 ss: 0018 > > Process dnetc (pid: 2152, stackpage=c0e41000) > > Stack: ff00 c01c976b c1b5ce80 ff00 c1b5ce80 c01c9d53 > c1b5ce80 c11fa800 > c1b5ce80 000e c1b5ce80 ffe6 c01cc667 c1b5ce80 > 0020 0004 > c1979b20 000e c01d0cdd c1b5ce80 0001 > c1b5ce80 c01dabf0 > > Call Trace: [] [] [] > [] [] > [] [] > [] [] [] > [] [] > [] [] [] > > ^ f or 1 ? > (that's the f in the third entry, for those not using fixed > width fonts :) > [] [] [] > [] [] > [] [] [] > [] > > Code: 8b 1b 8b 42 70 83 f8 01 74 0b f0 ff 4a 70 0f 94 c0 84 c0 > 74 > Kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing. i can trigger this bug by simply typing ctrl-c in an ftp or ssh session from a machine on the local (masqueraded) network to the internet. some folks have blamed the ppp/pppoe code, but after further testing it does seem to be netfilter-related somehow, since i cannot reproduce the oops on the router itself with iptables modules unloaded. it only happens on a machine on the local network when masqueraded via the router. does this assumption make sense ? i was pointed to a ppp patch from lkml, but it seems to be relevant only to starting/stopping a ppp device. (message "[PATCH] ppp_generic.c - kfree(ppp) called twice") right now, i'm trying 2.4.7-pre8, it has a load of ppp related patches. it's still compiling atm. getting confused... jörn -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: kernel lockup in 2.4.5-ac3 and 2.4.6-pre7 (netfilter ?)
[christian, i'm quoting a message of yours below. maybe this is of interest to you, so i'm cc:ing] Thomas wrote: Jörn Nettingsmeier wrote: hello brad, hello netfilter people ! Brad Chapman wrote: Were you able to rescue any console output from the hard lockup; i.e. you did a klogd -c 7 to capture _everything_ the kernel spit out? If you were able to, could you send them to the list, please? i have just reproduced the lockup with the klogd setting you suggested, but no entries at all have survived. however, it has been pointed out to me that my lockups might be caused by a faulty pppoe module (i'm using a dsl connection) rather than netfilter. it looks like i need to investigate a little further on pppoe... let's see what the lkml archive has to say. thanks for all the helpful replies. i will keep you posted if i can solve this problem. Hi, i can't help you exactly, but i also use T-Dsl and also there it come to hangup's ( sometimes kernel panic ) At the moment i get it off, i switched the debug mode on and log all the crap in an file ( hoped i find the error ) but after debug on there was no more hangup. I'm sure it is an bug in the pppoe system, wich come to work when the T* have trouble and send defekt packets. The ground i think it have to do with defekt packets is that other frinds with dsl under windoff told me that they also have on the same time many disconnects. Cu thomas i found someone else's oops report on lkml, and this is exactly the one i'm seeing, although i can't save it for lack of a serial console: christian wrote on lkml: PROBLEM: Kernel Panics since i switched to T-DSL, using masquadering. Supposed to be fixed in 2.4.5pre9 ? virtual address 8ba7 *pde = Oops = CPU = 0 EIP = 0010:[c01c96c9] EFLAGS: 00010202 eax: c1569940 ebx: 8ba7 ecx: edx: 00068ba7 esi: c1b5ce80 edi: c15697e0 ebp: 0060 esp: c0e41dd4 ds: 0018 es: 0018 ss: 0018 Process dnetc (pid: 2152, stackpage=c0e41000) Stack: ff00 c01c976b c1b5ce80 ff00 c1b5ce80 c01c9d53 c1b5ce80 c11fa800 c1b5ce80 000e c1b5ce80 ffe6 c01cc667 c1b5ce80 0020 0004 c1979b20 000e c01d0cdd c1b5ce80 0001 c1b5ce80 c01dabf0 Call Trace: [c01c976b] [c01c9d53] [c01ccdd7] [c01d0cdd] [c01dabf0] [c01dacb0] [c01d1ef8] [c01d8240] [c01dabd2] [c01dabf0] [c01d829a] [c01d1ef8] [c01d8fd6] [c01d8240] [c01d7290] ^ f or 1 ? (that's the f in the third entry, for those not using fixed width fonts :) [c01d742d] [c01d7290] [c01d1ef8] [c01d70d6] [c01d7290] [c01cd59e] [c0116b8a] [c01085cb] [c0106d04] Code: 8b 1b 8b 42 70 83 f8 01 74 0b f0 ff 4a 70 0f 94 c0 84 c0 74 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing. i can trigger this bug by simply typing ctrl-c in an ftp or ssh session from a machine on the local (masqueraded) network to the internet. some folks have blamed the ppp/pppoe code, but after further testing it does seem to be netfilter-related somehow, since i cannot reproduce the oops on the router itself with iptables modules unloaded. it only happens on a machine on the local network when masqueraded via the router. does this assumption make sense ? i was pointed to a ppp patch from lkml, but it seems to be relevant only to starting/stopping a ppp device. (message [PATCH] ppp_generic.c - kfree(ppp) called twice) right now, i'm trying 2.4.7-pre8, it has a load of ppp related patches. it's still compiling atm. getting confused... jörn -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: kernel lockup in 2.4.5-ac3 and 2.4.6-pre7 (netfilter ?)
just fyi, 2.4.7-pre8 did not cure the problem. i was able to reproduce the problem like before. this time, i switched to the log console before locking the machine up, and the oops is in fact identical to the one christian was seeing. the last line says In interrupt handler - not syncing. which seems to explain why no syslog messages survive. regards, jörn -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: [PATCH] fbdev logo (fwd)
why not make the preferred beverage a compile-time option ? this would make a nice menu in the framebuffer section... CONFIG_FB_LOGO CONFIG_FB_LOGO_BEER CONFIG_FB_LOGO_WINE CONFIG_FB_LOGO_VODKA CONFIG_FB_LOGO_MILK (for the sake of political correctness, this should be the default) CONFIG_FB_LOGO_CIGAR CONFIG_FB_LOGO_MD5 -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: [PATCH] fbdev logo (fwd)
why not make the preferred beverage a compile-time option ? this would make a nice menu in the framebuffer section... CONFIG_FB_LOGO CONFIG_FB_LOGO_BEER CONFIG_FB_LOGO_WINE CONFIG_FB_LOGO_VODKA CONFIG_FB_LOGO_MILK (for the sake of political correctness, this should be the default) CONFIG_FB_LOGO_CIGAR CONFIG_FB_LOGO_MD5 -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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.4.4-pre6 does not compile
jochen wrote: > > Hi, > > 2.4.4-pre6 actually is the 4th 2.4.4pre-Patch that does not compile > without further patching on my system. :-( > > > ld -m elf_i386 -T /usr/src/linux-2.4.4-pre6/arch/i386/vmlinux.lds -e stext > arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o >init/version.o \ > --start-group \ > arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o >fs/fs.o > ipc/ipc.o \ > drivers/block/block.o drivers/char/char.o drivers/misc/misc.o > drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o > drivers/scsi/scsidrv.o drivers/scsi/aic7xxx/aic7xxx_drv.o >drivers/cdrom/driver.o > drivers/pci/driver.o drivers/video/video.o \ > net/network.o \ > /usr/src/linux-2.4.4-pre6/arch/i386/lib/lib.a > /usr/src/linux-2.4.4-pre6/lib/lib.a >/usr/src/linux-2.4.4-pre6/arch/i386/lib/lib.a \ > --end-group \ > -o vmlinux > /usr/src/linux-2.4.4-pre6/lib/lib.a(rwsem.o): In function `__rwsem_do_wake': > rwsem.o(.text+0x30): undefined reference to `__builtin_expect' > rwsem.o(.text+0x73): undefined reference to `__builtin_expect' > make: *** [vmlinux] Error 1 same problem here. i'm using # gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) and this one has successfully built the last couple of kernels. if compiler requirements have changed, may i humbly suggest to add this to the pre-patch logfile ? btw: i have installed clean vanilla sources. the only possible source of pollution was my old .config, which i copied into the tree before making menuconfig. but this has always worked before. regards, jörn (please cc: me, i only read the archives, which have some lag. thanks.) -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://www.folkwang.uni-essen.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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.4.4-pre6 does not compile
jochen wrote: Hi, 2.4.4-pre6 actually is the 4th 2.4.4pre-Patch that does not compile without further patching on my system. :-( ld -m elf_i386 -T /usr/src/linux-2.4.4-pre6/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/scsi/aic7xxx/aic7xxx_drv.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o \ net/network.o \ /usr/src/linux-2.4.4-pre6/arch/i386/lib/lib.a /usr/src/linux-2.4.4-pre6/lib/lib.a /usr/src/linux-2.4.4-pre6/arch/i386/lib/lib.a \ --end-group \ -o vmlinux /usr/src/linux-2.4.4-pre6/lib/lib.a(rwsem.o): In function `__rwsem_do_wake': rwsem.o(.text+0x30): undefined reference to `__builtin_expect' rwsem.o(.text+0x73): undefined reference to `__builtin_expect' make: *** [vmlinux] Error 1 same problem here. i'm using # gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) and this one has successfully built the last couple of kernels. if compiler requirements have changed, may i humbly suggest to add this to the pre-patch logfile ? btw: i have installed clean vanilla sources. the only possible source of pollution was my old .config, which i copied into the tree before making menuconfig. but this has always worked before. regards, jörn (please cc: me, i only read the archives, which have some lag. thanks.) -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://www.folkwang.uni-essen.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: 8139too.c and 2.4.4-pre1 kernel burp
hello jeff ! with the 8139too v. 0.9.16 from http://sourceforge.net/projects/gkernel/ and kernel 2.4.4-pre3, i see no more errors of the "too much work at interrupt" type. i used to see the errors even under normal load, starting immediately after booting. so far, i did some nfs and flood-pinging, and all seems to be well. if you want me to run more specific tests, let me know. thanks, jörn Jeff Garzik wrote: > > Jörn Nettingsmeier wrote: > > > > jeff garzik wrote: > > > > > > Frank Jacobberger wrote: > > > > > > > > Jeff, > > > > > > > > I noticed the following on boot with 2.4.4-pre1: > > > > > > > > kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. > > > > > > > > What is this saying to me :) > > > > > > How often does this occur? A lot, or just once or twice? > > > > i'm seeing this, too. it occurs *very* often during access of the > > card: > > > > Apr 13 11:08:11 kleineronkel kernel: eth0: Too much work at > > interrupt, IntrStatus=0x0001. > > Apr 13 11:08:44 kleineronkel last message repeated 869 times > > Apr 13 11:09:29 kleineronkel last message repeated 59 times > > Apr 13 11:10:04 kleineronkel last message repeated 2 times > > Apr 13 11:11:43 kleineronkel last message repeated 149 times > > Apr 13 11:11:59 kleineronkel last message repeated 4 times > > Apr 13 11:13:01 kleineronkel last message repeated 7 times > > Apr 13 11:15:01 kleineronkel kernel: eth0: Too much work at > > interrupt, IntrStatus=0x0001. > > Apr 13 11:16:15 kleineronkel last message repeated 6 times > > Apr 13 11:16:15 kleineronkel kernel: eth0: Too much work at > > interrupt, IntrStatus=0x0001. > > Apr 13 11:18:01 kleineronkel last message repeated 5 times > > Apr 13 11:18:06 kleineronkel modprobe: modprobe: Can't locate module > > net-pf-10 > > Apr 13 11:18:08 kleineronkel sshd[1631]: Accepted password for ROOT > > from 127.0.0.1 port 32948 > > Apr 13 11:18:08 kleineronkel modprobe: modprobe: Can't locate module > > net-pf-10 > > Apr 13 11:18:09 kleineronkel kernel: eth0: Too much work at > > interrupt, IntrStatus=0x0001. > > > > and so on. > > > > it might be important that i'm sharing the IRQ: > > > > kleineronkel:~ # cat /proc/interrupts > >CPU0 CPU1 > > 0: 294470 246477IO-APIC-edge timer > > 1: 4552 5266IO-APIC-edge keyboard > > 2: 0 0 XT-PIC cascade > > 8: 2 0IO-APIC-edge rtc > > 12: 29084 29205IO-APIC-edge PS/2 Mouse > > 14: 4 4IO-APIC-edge ide0 > > 15: 4924 5704IO-APIC-edge ide1 > > 16: 1256 1373 IO-APIC-level EMU10K1 > > 17: 0 0 IO-APIC-level Ensoniq AudioPCI > > 19: 76145 76111 IO-APIC-level aic7xxx, eth0 > > NMI: 0 0 > > LOC: 540865 540843 > > ERR: 0 > > > > and yes, this is an SMP box (dual p3/600) with a bx chipset. > > > > please keep me on cc:, as i have only archive access to LKML. > > thanks. > > btw, jeff, the old "kernel: eth0: Abnormal interrupt, status > > 000[2,6]" messages have disappeared since 2.4.3 or so. > > I've fixed this locally. I just need to test all the RTL chips (five or > six variants) before I send the next patch to Linus/Alan... > > -- > Jeff Garzik | Sam: "Mind if I drive?" > Building 1024 | Max: "Not if you don't mind me clawing at the dash > MandrakeSoft | and shrieking like a cheerleader." -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: 8139too.c and 2.4.4-pre1 kernel burp
hello jeff ! with the 8139too v. 0.9.16 from http://sourceforge.net/projects/gkernel/ and kernel 2.4.4-pre3, i see no more errors of the "too much work at interrupt" type. i used to see the errors even under normal load, starting immediately after booting. so far, i did some nfs and flood-pinging, and all seems to be well. if you want me to run more specific tests, let me know. thanks, jrn Jeff Garzik wrote: Jrn Nettingsmeier wrote: jeff garzik wrote: Frank Jacobberger wrote: Jeff, I noticed the following on boot with 2.4.4-pre1: kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. What is this saying to me :) How often does this occur? A lot, or just once or twice? i'm seeing this, too. it occurs *very* often during access of the card: Apr 13 11:08:11 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. Apr 13 11:08:44 kleineronkel last message repeated 869 times Apr 13 11:09:29 kleineronkel last message repeated 59 times Apr 13 11:10:04 kleineronkel last message repeated 2 times Apr 13 11:11:43 kleineronkel last message repeated 149 times Apr 13 11:11:59 kleineronkel last message repeated 4 times Apr 13 11:13:01 kleineronkel last message repeated 7 times Apr 13 11:15:01 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. Apr 13 11:16:15 kleineronkel last message repeated 6 times Apr 13 11:16:15 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. Apr 13 11:18:01 kleineronkel last message repeated 5 times Apr 13 11:18:06 kleineronkel modprobe: modprobe: Can't locate module net-pf-10 Apr 13 11:18:08 kleineronkel sshd[1631]: Accepted password for ROOT from 127.0.0.1 port 32948 Apr 13 11:18:08 kleineronkel modprobe: modprobe: Can't locate module net-pf-10 Apr 13 11:18:09 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. and so on. it might be important that i'm sharing the IRQ: kleineronkel:~ # cat /proc/interrupts CPU0 CPU1 0: 294470 246477IO-APIC-edge timer 1: 4552 5266IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 2 0IO-APIC-edge rtc 12: 29084 29205IO-APIC-edge PS/2 Mouse 14: 4 4IO-APIC-edge ide0 15: 4924 5704IO-APIC-edge ide1 16: 1256 1373 IO-APIC-level EMU10K1 17: 0 0 IO-APIC-level Ensoniq AudioPCI 19: 76145 76111 IO-APIC-level aic7xxx, eth0 NMI: 0 0 LOC: 540865 540843 ERR: 0 and yes, this is an SMP box (dual p3/600) with a bx chipset. please keep me on cc:, as i have only archive access to LKML. thanks. btw, jeff, the old "kernel: eth0: Abnormal interrupt, status 000[2,6]" messages have disappeared since 2.4.3 or so. I've fixed this locally. I just need to test all the RTL chips (five or six variants) before I send the next patch to Linus/Alan... -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." -- Jrn Nettingsmeier home://Kurfrstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: 8139too.c and 2.4.4-pre1 kernel burp
Jörn Nettingsmeier wrote: > > i'm seeing this, too. forgot to mention: i'm running 2.4.4-pre2 here. problem persists. -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: 8139too.c and 2.4.4-pre1 kernel burp
jeff garzik wrote: > > Frank Jacobberger wrote: > > > > Jeff, > > > > I noticed the following on boot with 2.4.4-pre1: > > > > kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. > > > > What is this saying to me :) > > How often does this occur? A lot, or just once or twice? i'm seeing this, too. it occurs *very* often during access of the card: Apr 13 11:08:11 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. Apr 13 11:08:44 kleineronkel last message repeated 869 times Apr 13 11:09:29 kleineronkel last message repeated 59 times Apr 13 11:10:04 kleineronkel last message repeated 2 times Apr 13 11:11:43 kleineronkel last message repeated 149 times Apr 13 11:11:59 kleineronkel last message repeated 4 times Apr 13 11:13:01 kleineronkel last message repeated 7 times Apr 13 11:15:01 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. Apr 13 11:16:15 kleineronkel last message repeated 6 times Apr 13 11:16:15 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. Apr 13 11:18:01 kleineronkel last message repeated 5 times Apr 13 11:18:06 kleineronkel modprobe: modprobe: Can't locate module net-pf-10 Apr 13 11:18:08 kleineronkel sshd[1631]: Accepted password for ROOT from 127.0.0.1 port 32948 Apr 13 11:18:08 kleineronkel modprobe: modprobe: Can't locate module net-pf-10 Apr 13 11:18:09 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. and so on. it might be important that i'm sharing the IRQ: kleineronkel:~ # cat /proc/interrupts CPU0 CPU1 0: 294470 246477IO-APIC-edge timer 1: 4552 5266IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 2 0IO-APIC-edge rtc 12: 29084 29205IO-APIC-edge PS/2 Mouse 14: 4 4IO-APIC-edge ide0 15: 4924 5704IO-APIC-edge ide1 16: 1256 1373 IO-APIC-level EMU10K1 17: 0 0 IO-APIC-level Ensoniq AudioPCI 19: 76145 76111 IO-APIC-level aic7xxx, eth0 NMI: 0 0 LOC: 540865 540843 ERR: 0 and yes, this is an SMP box (dual p3/600) with a bx chipset. please keep me on cc:, as i have only archive access to LKML. thanks. btw, jeff, the old "kernel: eth0: Abnormal interrupt, status 000[2,6]" messages have disappeared since 2.4.3 or so. regards, jörn -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: 8139too.c and 2.4.4-pre1 kernel burp
jeff garzik wrote: Frank Jacobberger wrote: Jeff, I noticed the following on boot with 2.4.4-pre1: kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. What is this saying to me :) How often does this occur? A lot, or just once or twice? i'm seeing this, too. it occurs *very* often during access of the card: Apr 13 11:08:11 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. Apr 13 11:08:44 kleineronkel last message repeated 869 times Apr 13 11:09:29 kleineronkel last message repeated 59 times Apr 13 11:10:04 kleineronkel last message repeated 2 times Apr 13 11:11:43 kleineronkel last message repeated 149 times Apr 13 11:11:59 kleineronkel last message repeated 4 times Apr 13 11:13:01 kleineronkel last message repeated 7 times Apr 13 11:15:01 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. Apr 13 11:16:15 kleineronkel last message repeated 6 times Apr 13 11:16:15 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. Apr 13 11:18:01 kleineronkel last message repeated 5 times Apr 13 11:18:06 kleineronkel modprobe: modprobe: Can't locate module net-pf-10 Apr 13 11:18:08 kleineronkel sshd[1631]: Accepted password for ROOT from 127.0.0.1 port 32948 Apr 13 11:18:08 kleineronkel modprobe: modprobe: Can't locate module net-pf-10 Apr 13 11:18:09 kleineronkel kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. and so on. it might be important that i'm sharing the IRQ: kleineronkel:~ # cat /proc/interrupts CPU0 CPU1 0: 294470 246477IO-APIC-edge timer 1: 4552 5266IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 2 0IO-APIC-edge rtc 12: 29084 29205IO-APIC-edge PS/2 Mouse 14: 4 4IO-APIC-edge ide0 15: 4924 5704IO-APIC-edge ide1 16: 1256 1373 IO-APIC-level EMU10K1 17: 0 0 IO-APIC-level Ensoniq AudioPCI 19: 76145 76111 IO-APIC-level aic7xxx, eth0 NMI: 0 0 LOC: 540865 540843 ERR: 0 and yes, this is an SMP box (dual p3/600) with a bx chipset. please keep me on cc:, as i have only archive access to LKML. thanks. btw, jeff, the old "kernel: eth0: Abnormal interrupt, status 000[2,6]" messages have disappeared since 2.4.3 or so. regards, jrn -- Jrn Nettingsmeier home://Kurfrstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: 8139too.c and 2.4.4-pre1 kernel burp
Jrn Nettingsmeier wrote: i'm seeing this, too. forgot to mention: i'm running 2.4.4-pre2 here. problem persists. -- Jrn Nettingsmeier home://Kurfrstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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: yacc dependency of aic7xxx driver
"Justin T. Gibbs" wrote: > > >hello justin ! > > > >i have just tried to install the latest 2.4.3pre3 kernel with your > >driver. > >it failed with yacc: file not found. > >while i could install yacc, i have never had to use it before. i was > >assuming that the newer bison could do the same thing (which is what > >i have installed). > >so far, the kernel has not relied on yacc, which is why i'd like to > >ask you if it's possible to make it work with bison. > > The assembler makefile doesn't reference yacc, but instead relies > on gmake's built in rules to figure out how to generate a .c from > a .y. I'm somewhat surprised that bison doesn't create a link to > yacc or that gmake doesn't try to look for bison. > > Oh well. We'll just have to be more careful in how future patches > are generated so that the dependency between the generated firmware > files and the firmware source only triggers if you are actually > performing firmware development. Trying to build this simple > assmebler on everyone's systems is turning out to be just too > hard. i might also be SuSE 7.1 related, since this was the first kernel i compiled on the new distro. but since the problem arose only with the new aic driver, i thought it might be that you had a slightly different development environment...? anyway, robbert muller sent me the following simple workaround: Just create a shell script called yacc with the following content --- #!/bin/sh bison --yacc $* --- i ran into the same problem with a school proiject here yesterday regards, jörn -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://www.folkwang-hochschule.de/~nettings/ - 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/
yacc dependency of aic7xxx driver
hello justin ! i have just tried to install the latest 2.4.3pre3 kernel with your driver. it failed with yacc: file not found. while i could install yacc, i have never had to use it before. i was assuming that the newer bison could do the same thing (which is what i have installed). so far, the kernel has not relied on yacc, which is why i'd like to ask you if it's possible to make it work with bison. sorry if this has been dealt with before, but i didn't find anything in the lkml archive. regards, jörn please keep me cc:ed, i'm not on lkml. thanks. -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://www.folkwang-hochschule.de/~nettings/ - 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/
video drivers hog pci bus ? [was:[linux-audio-dev] low-latency scheduling patch for 2.4.0]
; > What needs to happen is for the xfree guys to add a > control flag to XF86Config for this. I believe they > have - it's called `PCIRetry'. > > I believe PCIRetry defaults to `off'. This is bad. > It should default to `on'. > > You can read about this minor scandal at the following > URLs: > > http://www.zefiro.com/vgakills.txt > http://www.zdnet.com/pcmag/news/trends/t980619a.htm > http://www.research.microsoft.com/~mbj/papers/tr-98-29.html > > So, we need to talk to the xfree team. > > Whoops! I accidentally Cc'ed them :-) > > - -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://www.folkwang.uni-essen.de/~nettings/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
video drivers hog pci bus ? [was:[linux-audio-dev] low-latency scheduling patch for 2.4.0]
[alsa folks, i'd appreciate a comment on this thread from linux-audio-dev] hello everyone ! in a post related to his latest low-latency patch, andrew morton gave a pointer to http://www.zefiro.com/vgakills.txt , which addresses the problem of dropped samples due to agressive video drivers hogging the pci bus with retry attempts to optimize benchmark results while producing a "zipper" noise, e.g. when moving windows around with the mouse while playing a soundfile. some may have tried fiddling with the "pci retry" option in the XF86Config (see the linux audio quality howto by paul winkler at http://www.linuxdj.com/audio/quality for details). i recall some people having reported mysterious l/r swaps w/ alsa drivers on some cards, and iirc, most of these reports were not easily reproduced and explained. the zefiro paper states that the zefiro cards would swap channels occasionally under the circumstances mentioned. it sounds probable to me that all drivers using interleaved data would suffer from this problem. can some more experienced people comment on this ? is my assumption correct that the bus hogging behaviour is affected by the pci_retry option ? btw: the text only mentions pci video cards. will agp cards also clog the pci bus ? please give some detail in your answers - i would like to include this in the linux-audio-dev faq and resources pages. (so chances are you will only have to answer this once :) sorry if this has been dealt with before, i seem to have trouble to follow all my mailing lists... regards, jrn Andrew Morton wrote: A patch against kernel 2.4.0 final which provides low-latency scheduling is at http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads Some notes: - Worst-case scheduling latency with *very* intense workloads is now 0.8 milliseconds on a 500MHz uniprocessor. Neither, I think. We can't apply some patch and say "there; it's low-latency". We (or "he") need to decide up-front that Linux is to become a low latency kernel. Then we need to decide the best way of doing that. Making the kernel internally preemptive is probably the best way of doing this. But it's a *big* task to which must beard-scratching must be put. It goes way beyond the preemptive-kernel patches which have thus far been proposed. I could propose a simple patch for 2.4 (say, the ten most-needed scheduling points). This would get us down to maybe 5-10 milliesconds under heavy load (10-20x improvement). That would probably be a great and sufficient improvement for the HA heartbeat monitoring apps, the database TP monitors, the QuakeIII players and, of course, people who are only interested in audio record and playback - I'd need advice from the audio experts for that. I hope that one or more of the desktop-oriented Linux distributors discover that hosing HTML out of gigE ports is not really the One True Appplication of Linux, and that they decide to offer a low-latency kernel for the other 99.99% of Linux users. Well it's extremely nice to see NFS included at least. I was really worried about that one. What about Samba? (Keeping in mind that serious "professional" musicians will likely have their Linux systems networked to a Windows box, at least until they have all the necessary tools on Linux. - If you care about latency, be *very* cautious about upgrading to XFree86 4.x. I'll cover this issue in a separate email, copied to the XFree team. I haven't gathered the energy to send it. The basic problem with many video cards is this: Video adapters have on-board command FIFOs. They also have a "FIFO has spare room" control bit. If you write to the FIFO when there is no spare room, the damned thing busies the PCI bus until there *is* room. This can be up to twenty *milliseconds*. This will screw up realtime operating systems, will cause network receive overruns, will screw up isochronous protocols such as USB and 1394 and will of course screw up scheduling latency. In xfree3 it was OK - the drivers polled the "spare room" bit before writing. But in xfree4 the drivers are starting to take advantage of this misfeature. I am told that a significant number of people are backing out xfree4 upgrades because of this. For audio. The manufacturers got caught out by the trade press in '98 and '99 and they added registry flags to their drivers to turn off this obnoxious behaviour. What needs to happen is for the xfree guys to add a control flag to XF86Config for this. I believe they have - it's called `PCIRetry'. I believe PCIRetry defaults to `off'. This is bad. It should default to `on'. You can read about this minor scandal at the following URLs: http://www.zefiro.com/vgakills.txt http://www.zdnet.com/pcmag/news/trends/t980619a.htm http://www.research.microsoft.com/~mbj/papers/tr-98-29.html So, we need to talk to the
