Re: why am i seeing a ~60-second network connection delay with2.4.0test*?
I'm using 2.4-test since it was born and never saw this behavior. Could you please strace and ltrace your ping so we can see where it waits? Martin On Sun, 3 Sep 2000, John Kennedy wrote: > I've been having a problem with the 2.4.0 series (tested most recently > against test8-pre1)... there is a long (seems to be almost exactly > ~60 seconds, but you have to be careful about racking up multiples) > delay trying to make outgoing connections, including pings: > > root@pandora: time ping -c1 xxx.xxx.60.33 > PING xxx.xxx.60.33 (xxx.xxx.60.33): 56 data bytes > 64 bytes from xxx.xxx.60.33: icmp_seq=0 ttl=64 time=2.312 ms > > --- xxx.xxx.60.33 ping statistics --- > 1 packets transmitted, 1 packets received, 0% packet loss > round-trip min/avg/max = 2.312/2.311/2.312 ms > > real1m0.121s > user0m0.000s > sys 0m0.000s > > The connections all seem to work if you wait out the minute. I've tried > this on a desktop and a laptop with the same results. > > Suggestions? > ------------ Martin "MaD" Douda WEB: http://martin.douda.net/ PHONE:+420603752779 ICQ# 86467013 EMAIL: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> (160 characters only) PGP:ID=0x6FE43023 Fingerprint:E495 11DA EF6E 0DD6 965A 54F3 888E CC9E 6FE4 3023 Po uvedeni Windows 2000 zacne Microsoft vyvijet novy system, ktery by se mel stat novou vlajkovou lodi v oblasti operacnich systemu. Tiskovy mluvci take prozradil, ze kodove jmeno projektu bude Titanic. - 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/
if (CONFIG_FOO) Re: 2.4.0-test8-pre1 is quite bad / how aboutintegrating Rik's VM
On Tue, 5 Sep 2000, Alexander Viro wrote: > > The _real_ problem is preprocessor abuse. BTW, could we schedule for > 2.5 the following? > * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is. > * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused > branches just fine. > * Yes, Virginia, it means that controlflow-affecting expansion has to > go. Good riddance, IMO. > > Goal: making sure that every bloody line of the files we choose to > compile goes through the parser. Will do wonders with test coverage and will > make analysis tools like tags viable. Then we can just use the gcc frontend > output as input for such beasts. > Problem: every bloody line will go through the parser. There is too many lines. Compilation is realy slow today. I'm affraid this approach would make it worse. Note that 2.4.0-test7 has more than 2.75 milion lines. Or did you mean drivers will be (optionally?) excluded from this compile-it-all-and-then-optimize-it-away? I can understand advantages the if(CONFIG_FOO) approach has, but I'm not sure it is worth compilation slowdown. Martin ------------ Martin "MaD" Douda WEB: http://martin.douda.net/ PHONE:+420603752779 ICQ# 86467013 EMAIL: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> (160 characters only) PGP:ID=0x6FE43023 Fingerprint:E495 11DA EF6E 0DD6 965A 54F3 888E CC9E 6FE4 3023 [1]+ Done rm -rf / - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available
On Fri, 19 Jan 2001, Michael Lindner wrote: > data is generated as a result of data received via a select(), > the next delivery occurs a clock tick later, with the machine > mostly idle. ^^^ The machine is in fact not idle - there is a task running - idle task. Could the problem be that scheduler does not preempt this task to run something more useful? Symptoms seems to show this. Martin - 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/
100% repeatable OOPS
- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- AuxPwr- DSI- D1- D2- PME- Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc.: Unknown device Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K] Capabilities: [60] Power Management version 1 Flags: PMEClk- AuxPwr- DSI- D1- D2- PME- Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [44] AGP version 2.0 Status: RQ=31 SBA- 64bit- FW- Rate=x1,x2 Command: RQ=0 SBA- AGP- 64bit- FW- Rate= [7.6.] SCSI information (from /proc/scsi/scsi) no SCSI here. [7.7.] Other information that might be relevant to the problem (please look in /proc and include all information that you think to be relevant): [X.] Other notes, patches, fixes, workarounds: The most interesting information is this: EIP::[<0253>] Kernel really jumped to some random address. I've no idea, how it is possible. But this definitely should not happen. Feel free to ask for more information. Have a nice day. Martin Douda -------- Martin "MaD" Douda WEB: http://martin.douda.net/ PHONE:+420603752779 ICQ# 86467013 EMAIL: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> (160 characters only) PGP:ID=0x6FE43023 Fingerprint:E495 11DA EF6E 0DD6 965A 54F3 888E CC9E 6FE4 3023 Don't hit the keys so hard, it hurts. - 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/