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/
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
s: 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/
100% repeatable OOPS
(32-bit, prefetchable) [size=32M] Expansion ROM at unassigned [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=none [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/
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: 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/
