* RE: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
@ 2001-12-18 9:33 Mika.Liljeberg
2001-12-18 18:37 ` kuznet
0 siblings, 1 reply; 22+ messages in thread
From: Mika.Liljeberg @ 2001-12-18 9:33 UTC (permalink / raw)
To: kuznet; +Cc: davem, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]
HI again Alexey,
We had the missing FIN retransmit problem recur a few times.
> It is possible _only_ if rto is at 120 seconds. It is the only case
> when retransmissions do not happen and this would be normal behaviour.
>
> For now it is the only hypothesis and it will be clear from
> /proc/net/tcp, whether is this right or not.
Again, 10.0.5.11 is Linux, 10.0.5.3 is Symbian. The FIN-ACK from Linux to
Symbian gets dropped. Symbian retransmits the FIN, which is acked by Linux.
Nothing happens after this. Linux eventually times out from LAST-ACK and
Symbian remains stuck in FIN-WAIT-2.
The dump plus /proc/net/tcp is attached. As you can see, no data is
transferred from Linux to Symbian, so the only RTT sample for Linux comes
from the SYN exchange (about 200 ms). So, something is wrong?
Cheers,
MikaL
----------------------------------------------------------------
Mika Liljeberg Phone: +358 5048 36791
Nokia Research Center Fax: +358 7180 36850
P.O.Box 407 Email: mika.liljeberg@nokia.com
FIN-00045 NOKIA GROUP Office: Itämerenkatu 11-13,
Finland FIN-00180, Helsinki, Finland
----------------------------------------------------------------
[-- Attachment #2: remote.txt --]
[-- Type: text/plain, Size: 4412 bytes --]
11:28:24.313303 10.0.5.3.3866 > 10.0.5.11.1545: S [tcp sum ok] 550414008:550414008(0) win 7300 <mss 1460,timestamp 3412683347 0,sackOK> (DF) (ttl 63, id 8156, len 56)
11:28:24.313344 10.0.5.11.1545 > 10.0.5.3.3866: S [tcp sum ok] 1891446655:1891446655(0) ack 550414009 win 5792 <mss 1460,sackOK,timestamp 8851207 3412683347> (DF) (ttl 64, id 0, len 56)
11:28:24.518049 10.0.5.3.3866 > 10.0.5.11.1545: . [tcp sum ok] 1:1(0) ack 1 win 7300 <timestamp 3412902097 8851207,eol> (DF) (ttl 63, id 8157, len 52)
11:28:24.532032 10.0.5.3.3866 > 10.0.5.11.1545: . 257:1705(1448) ack 1 win 7300 <timestamp 3412902097 8851207,eol> (DF) (ttl 63, id 8159, len 1500)
11:28:24.532080 10.0.5.11.1545 > 10.0.5.3.3866: . [tcp sum ok] 1:1(0) ack 1 win 5792 <nop,nop,timestamp 8851229 3412902097,nop,nop,sack sack 1 {257:1705} > (DF) (ttl 64, id 8348, len 64)
11:28:24.539958 10.0.5.3.3866 > 10.0.5.11.1545: . 1705:3153(1448) ack 1 win 7300 <timestamp 3412917722 8851207,eol> (DF) (ttl 63, id 8160, len 1500)
11:28:24.540008 10.0.5.11.1545 > 10.0.5.3.3866: . [tcp sum ok] 1:1(0) ack 1 win 5792 <nop,nop,timestamp 8851230 3412902097,nop,nop,sack sack 1 {257:3153} > (DF) (ttl 64, id 8349, len 64)
11:28:24.747778 10.0.5.3.3866 > 10.0.5.11.1545: . 3153:4601(1448) ack 1 win 7300 <timestamp 3413120847 8851207,eol> (DF) (ttl 63, id 8161, len 1500)
11:28:24.747828 10.0.5.11.1545 > 10.0.5.3.3866: . [tcp sum ok] 1:1(0) ack 1 win 5792 <nop,nop,timestamp 8851250 3412902097,nop,nop,sack sack 1 {257:4601} > (DF) (ttl 64, id 8350, len 64)
11:28:24.954233 10.0.5.3.3866 > 10.0.5.11.1545: P 1:257(256) ack 1 win 7300 <timestamp 3413323972 8851207,eol> (DF) (ttl 63, id 8162, len 308)
11:28:24.954289 10.0.5.11.1545 > 10.0.5.3.3866: . [tcp sum ok] 1:1(0) ack 4601 win 6432 <nop,nop,timestamp 8851271 3413323972> (DF) (ttl 64, id 8351, len 52)
11:28:25.164591 10.0.5.3.3866 > 10.0.5.11.1545: . 4601:6049(1448) ack 1 win 7300 <timestamp 3413542722 8851207,eol> (DF) (ttl 63, id 8163, len 1500)
11:28:25.164642 10.0.5.11.1545 > 10.0.5.3.3866: . [tcp sum ok] 1:1(0) ack 6049 win 8688 <nop,nop,timestamp 8851292 3413542722> (DF) (ttl 64, id 8352, len 52)
11:28:25.167478 10.0.5.3.3866 > 10.0.5.11.1545: . 6049:7497(1448) ack 1 win 7300 <timestamp 3413542723 8851207,eol> (DF) (ttl 63, id 8164, len 1500)
11:28:25.167530 10.0.5.11.1545 > 10.0.5.3.3866: . [tcp sum ok] 1:1(0) ack 7497 win 11584 <nop,nop,timestamp 8851292 3413542723> (DF) (ttl 64, id 8353, len 52)
11:28:48.030264 10.0.5.3.3866 > 10.0.5.11.1545: . 498345:499793(1448) ack 1 win 7300 <timestamp 3436402097 8851207,eol> (DF) (ttl 63, id 8581, len 1500)
11:28:48.030318 10.0.5.11.1545 > 10.0.5.3.3866: . [tcp sum ok] 1:1(0) ack 501241 win 65160 <nop,nop,timestamp 8853579 3436402097,nop,nop,sack sack 1 {502689:508577} > (DF) (ttl 64, id 8714, len 64)
11:28:48.033323 10.0.5.3.3866 > 10.0.5.11.1545: . 501241:502689(1448) ack 1 win 7300 <timestamp 3436402098 8851207,eol> (DF) (ttl 63, id 8582, len 1500)
11:28:48.033376 10.0.5.11.1545 > 10.0.5.3.3866: . [tcp sum ok] 1:1(0) ack 508577 win 65160 <nop,nop,timestamp 8853579 3436402098> (DF) (ttl 64, id 8715, len 52)
11:28:48.037908 10.0.5.3.3866 > 10.0.5.11.1545: . 508577:510025(1448) ack 1 win 7300 <timestamp 3436417722 8851207,eol> (DF) (ttl 63, id 8583, len 1500)
11:28:48.037974 10.0.5.11.1545 > 10.0.5.3.3866: . [tcp sum ok] 1:1(0) ack 510025 win 65160 <nop,nop,timestamp 8853580 3436417722> (DF) (ttl 64, id 8716, len 52)
11:28:48.246533 10.0.5.3.3866 > 10.0.5.11.1545: . 510025:511473(1448) ack 1 win 7300 <timestamp 3436620847 8851207,eol> (DF) (ttl 63, id 8584, len 1500)
11:28:48.246570 10.0.5.11.1545 > 10.0.5.3.3866: . [tcp sum ok] 1:1(0) ack 511473 win 65160 <nop,nop,timestamp 8853600 3436620847> (DF) (ttl 64, id 8717, len 52)
11:28:48.247274 10.0.5.3.3866 > 10.0.5.11.1545: FP 511473:512001(528) ack 1 win 7300 <timestamp 3436620848 8851207,eol> (DF) (ttl 63, id 8585, len 580)
11:28:48.247337 10.0.5.11.1545 > 10.0.5.3.3866: F [tcp sum ok] 1:1(0) ack 512002 win 65160 <nop,nop,timestamp 8853600 3436620848> (DF) (ttl 64, id 8718, len 52)
11:28:49.454437 10.0.5.3.3866 > 10.0.5.11.1545: FP 511473:512001(528) ack 1 win 7300 <timestamp 3437839597 8851207,eol> (DF) (ttl 63, id 8587, len 580)
11:28:49.454468 10.0.5.11.1545 > 10.0.5.3.3866: . [tcp sum ok] 2:2(0) ack 512002 win 65160 <nop,nop,timestamp 8853721 3437839597,nop,nop,sack sack 1 {511473:512002} > (DF) (ttl 64, id 8719, len 64)
[-- Attachment #3: proc.net.tcp.txt --]
[-- Type: text/plain, Size: 6191 bytes --]
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 00000000:3241 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1001 0 2246 1 c70e5b60 300 0 0 2 -1
1: 00000000:0203 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 205 1 c789c460 300 0 0 2 -1
2: 00000000:0025 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 183 1 c7a5b7c0 300 0 0 2 -1
3: 00000000:05E8 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1001 0 12119 1 c4da4b80 300 0 0 2 -1
4: 00000000:05E9 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1001 0 12120 1 c4da40a0 300 0 0 2 -1
5: 00000000:0009 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 180 1 c7f7a400 300 0 0 2 -1
6: 00000000:05EB 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 9381 1 c70e5080 300 0 0 2 -1
7: 00000000:05EC 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1001 0 12122 1 c4da4440 300 0 0 2 -1
8: 00000000:4E2C 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 191 1 c79e3b80 300 0 0 2 -1
9: 00000000:05ED 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1001 0 12123 1 c7f0c0c0 300 0 0 2 -1
10: 00000000:000D 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 182 1 c7a5b420 300 0 0 2 -1
11: 00000000:05EF 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1001 0 12126 1 c5efc420 300 0 0 2 -1
12: 00000000:004F 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 186 1 c79e3440 300 0 0 2 -1
13: 00000000:05F0 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1001 0 12127 1 c5efc080 300 0 0 2 -1
14: 00000000:1770 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 485 1 c6ecebe0 300 0 0 2 -1
15: 00000000:0050 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 474 1 c6ece840 300 0 0 2 -1
16: 00000000:0071 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 187 1 c79e37e0 300 0 0 2 -1
17: 00000000:0015 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 184 1 c7a5bb60 300 0 0 2 -1
19: 00000000:0017 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 185 1 c79e30a0 300 0 0 2 -1
20: 00000000:1F98 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 384 1 c7734820 300 0 0 2 -1
21: 00000000:0019 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 387 1 c7734bc0 300 0 0 2 -1
22: 0105000A:05F5 0205000A:0546 01 00000000:00000000 00:00000000 00000000 0 0 12148 1 c12804a0 21 4 27 3 -1
23: 0105000A:05F4 0205000A:0544 01 00000000:00000000 00:00000000 00000000 0 0 12147 1 c5c0e0e0 21 4 8 2 -1
24: 0B05000A:0609 0305000A:0F1A 09 00000001:00000000 01:000010AE 00000000 0 0 0 2 c60023e0 12000 4 30 2 -1
25: 0105000A:05EB 0105000A:05F1 01 00000000:00000000 00:00000000 00000000 0 0 12129 1 c5efcb60 21 0 0 2 -1
26: 0105000A:05F3 0105000A:05F0 01 00000000:00000000 00:00000000 00000000 0 0 12131 1 c365b060 21 0 0 2 -1
27: 0105000A:05F0 0105000A:05F3 01 00000000:00000000 00:00000000 00000000 1001 0 12141 1 c1280840 21 4 10 2 -1
28: 0105000A:05ED 0205000A:0540 01 00000000:00000000 00:00000000 00000000 1001 0 12143 1 c1280be0 21 0 0 2 -1
29: 0105000A:05EF 0105000A:05F2 01 00000000:00000000 00:00000000 00000000 1001 0 12139 1 c365b400 21 0 0 2 -1
30: 0105000A:05E9 0205000A:053E 01 00000000:00000000 00:00000000 00000000 1001 0 12135 1 c365bb40 21 4 26 2 -1
31: 0105000A:05EC 0205000A:053F 01 00000000:00000000 00:00000000 00000000 1001 0 12137 1 c1280100 21 4 4 2 -1
32: 0105000A:05F2 0105000A:05EF 01 00000000:00000000 00:00000000 00000000 0 0 12130 1 c365b7a0 21 0 0 2 -1
33: 0105000A:05EB 0105000A:05EE 01 00000000:00000000 00:00000000 00000000 0 0 12125 1 c7f0c800 21 4 21 2 -1
34: 0105000A:05E8 0205000A:053D 01 00000000:00000000 00:00000000 00000000 1001 0 12133 1 c7f0c460 21 0 0 2 -1
35: 0105000A:05EA 0205000A:05EB 01 00000000:00000000 00:00000000 00000000 1001 0 12121 1 c4da47e0 21 4 0 3 -1
36: 0105000A:05E6 0205000A:05EB 01 00000000:00000000 00:00000000 00000000 1001 0 12117 1 c219c800 21 0 0 2 -1
37: 0105000A:05E7 0205000A:05EB 01 00000000:00000000 00:00000000 00000000 1001 0 12118 1 c55aa160 21 4 8 2 -1
38: 0B05000A:3241 0305000A:0F07 01 00000000:00000000 00:00000000 00000000 1001 0 12181 1 c6002780 71 4 11 2 2
39: 0105000A:05EE 0105000A:05EB 01 00000000:00000000 00:00000000 00000000 1001 0 12124 1 c7f0cba0 21 4 18 2 -1
40: 0105000A:05F1 0105000A:05EB 01 00000000:00000000 00:00000000 00000000 1001 0 12128 1 c5efc7c0 21 0 0 2 -1
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 9:33 TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA] Mika.Liljeberg
@ 2001-12-18 18:37 ` kuznet
2001-12-18 20:21 ` Mika Liljeberg
0 siblings, 1 reply; 22+ messages in thread
From: kuznet @ 2001-12-18 18:37 UTC (permalink / raw)
To: Mika.Liljeberg; +Cc: davem, linux-kernel
Hello!
> from the SYN exchange (about 200 ms). So, something is wrong?
Well, the guess was right and this is pleasant.
The only minor :-) question remained is to guess how rto could happen
to be at this value. I will think. Well, if you have some guesses,
please, tell me. Is this intel btw? I just see that other side
sends bogus misaligned tcp options... not a problem, but it can
be reason of funnyies with some probability.
Alexey
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 18:37 ` kuznet
@ 2001-12-18 20:21 ` Mika Liljeberg
2001-12-18 20:28 ` David S. Miller
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Mika Liljeberg @ 2001-12-18 20:21 UTC (permalink / raw)
To: kuznet; +Cc: Mika.Liljeberg, davem, linux-kernel, sarolaht
kuznet@ms2.inr.ac.ru wrote:
>
> Hello!
>
> > from the SYN exchange (about 200 ms). So, something is wrong?
>
> Well, the guess was right and this is pleasant.
Yes. We also saw a case, where the RTO was quite high but not quite 120,
so we got exactly one retransmission.
> The only minor :-) question remained is to guess how rto could happen
> to be at this value. I will think. Well, if you have some guesses,
> please, tell me.
Sorry, I'm not really trying to debug Linux so I haven't given it much
thought. We're exercising retransmission algorithms with a packet loss
ratio of 5% if that's any help.
> Is this intel btw?
It's ARM in little endian mode.
> I just see that other side
> sends bogus misaligned tcp options... not a problem, but it can
> be reason of funnyies with some probability.
Heh, they're not bogus, just differently aligned. :) This is an
implementation where packet processing latency is not highest
item on the list of optimization targets.
Now that you mention it, tcp_parse_options() in input.c seems to expect
that the timestamps are word aligned, which is not the case here, and a
false assumption in any case. I would have expected a bus error for
that, unless the pointer cast generates code that magically word aligns
the resulting pointer...
Cheers,
MikaL
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 20:21 ` Mika Liljeberg
@ 2001-12-18 20:28 ` David S. Miller
2001-12-18 20:29 ` ARM: " kuznet
2001-12-20 7:31 ` Stevie O
2 siblings, 0 replies; 22+ messages in thread
From: David S. Miller @ 2001-12-18 20:28 UTC (permalink / raw)
To: Mika.Liljeberg; +Cc: kuznet, Mika.Liljeberg, linux-kernel, sarolaht
From: Mika Liljeberg <Mika.Liljeberg@welho.com>
Date: Tue, 18 Dec 2001 22:21:44 +0200
Now that you mention it, tcp_parse_options() in input.c seems to expect
that the timestamps are word aligned, which is not the case here, and a
false assumption in any case. I would have expected a bus error for
that, unless the pointer cast generates code that magically word aligns
the resulting pointer...
Unaligned kernel loads and stores must be properly handled by the
platform code, and on ARM chips where that is possible it is.
Nevertheless, if you'd like to rule this out, please try the
patch below:
diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/net/ipv4/tcp_input.c linux/net/ipv4/tcp_input.c
--- vanilla/linux/net/ipv4/tcp_input.c Tue Oct 30 15:08:12 2001
+++ linux/net/ipv4/tcp_input.c Tue Nov 6 15:48:01 2001
@@ -1987,6 +1987,18 @@
return 0;
}
+static __inline__ __u16 tcp_options_get16(unsigned char *p)
+{
+ return ((__u16) p[0] << 8) | (__u16) p[1];
+}
+
+static __inline__ __u32 tcp_options_get32(unsigned char *p)
+{
+ return (((__u32) p[0] << 24) |
+ ((__u32) p[1] << 16) |
+ ((__u32) p[2] << 8) |
+ ((__u32) p[3] << 0));
+}
/* Look for tcp options. Normally only called on SYN and SYNACK packets.
* But, this can also be called on packets in the established flow when
@@ -2020,7 +2032,7 @@
switch(opcode) {
case TCPOPT_MSS:
if(opsize==TCPOLEN_MSS && th->syn && !estab) {
- u16 in_mss = ntohs(*(__u16 *)ptr);
+ u16 in_mss = tcp_options_get16(ptr);
if (in_mss) {
if (tp->user_mss && tp->user_mss < in_mss)
in_mss = tp->user_mss;
@@ -2047,8 +2059,8 @@
if ((estab && tp->tstamp_ok) ||
(!estab && sysctl_tcp_timestamps)) {
tp->saw_tstamp = 1;
- tp->rcv_tsval = ntohl(*(__u32 *)ptr);
- tp->rcv_tsecr = ntohl(*(__u32 *)(ptr+4));
+ tp->rcv_tsval = tcp_options_get32(ptr);
+ tp->rcv_tsecr = tcp_options_get32(ptr + 4);
}
}
break;
^ permalink raw reply [flat|nested] 22+ messages in thread
* ARM: Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 20:21 ` Mika Liljeberg
2001-12-18 20:28 ` David S. Miller
@ 2001-12-18 20:29 ` kuznet
2001-12-18 20:52 ` Mika Liljeberg
2001-12-18 21:03 ` Russell King
2001-12-20 7:31 ` Stevie O
2 siblings, 2 replies; 22+ messages in thread
From: kuznet @ 2001-12-18 20:29 UTC (permalink / raw)
To: Mika Liljeberg; +Cc: Mika.Liljeberg, davem, linux-kernel, sarolaht, rmk
Hello!
> It's ARM in little endian mode.
I think it is answer to the question.
No doubts it still has broken misaligned access.
> Now that you mention it, tcp_parse_options() in input.c seems to expect
> that the timestamps are word aligned,
Nope. It does not expect any alignment, but it is really supposed
to penalise misbehaving cases.
Alexey
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ARM: Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 20:29 ` ARM: " kuznet
@ 2001-12-18 20:52 ` Mika Liljeberg
2001-12-18 21:08 ` David S. Miller
2001-12-18 21:03 ` Russell King
1 sibling, 1 reply; 22+ messages in thread
From: Mika Liljeberg @ 2001-12-18 20:52 UTC (permalink / raw)
To: kuznet; +Cc: Mika.Liljeberg, davem, linux-kernel, sarolaht, rmk
kuznet@ms2.inr.ac.ru wrote:
> > It's ARM in little endian mode.
>
> I think it is answer to the question.
>
> No doubts it still has broken misaligned access.
Oops, I think there was a misunderstanding. The linux machine is Intel.
The other one is a non-Linux ARM.
> > Now that you mention it, tcp_parse_options() in input.c seems to expect
> > that the timestamps are word aligned,
>
> Nope. It does not expect any alignment, but it is really supposed
> to penalise misbehaving cases.
Ahh, I see. There's a kernel exception handler that is supposed to fix
misaligned access? Hacky.
Cheers,
MikaL
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ARM: Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 20:29 ` ARM: " kuznet
2001-12-18 20:52 ` Mika Liljeberg
@ 2001-12-18 21:03 ` Russell King
2001-12-18 21:11 ` David S. Miller
1 sibling, 1 reply; 22+ messages in thread
From: Russell King @ 2001-12-18 21:03 UTC (permalink / raw)
To: kuznet; +Cc: Mika Liljeberg, Mika.Liljeberg, davem, linux-kernel, sarolaht
On Tue, Dec 18, 2001 at 11:29:06PM +0300, kuznet@ms2.inr.ac.ru wrote:
> > It's ARM in little endian mode.
>
> I think it is answer to the question.
>
> No doubts it still has broken misaligned access.
You're way out of line with that comment.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ARM: Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 20:52 ` Mika Liljeberg
@ 2001-12-18 21:08 ` David S. Miller
0 siblings, 0 replies; 22+ messages in thread
From: David S. Miller @ 2001-12-18 21:08 UTC (permalink / raw)
To: Mika.Liljeberg; +Cc: kuznet, Mika.Liljeberg, linux-kernel, sarolaht, rmk
From: Mika Liljeberg <Mika.Liljeberg@welho.com>
Date: Tue, 18 Dec 2001 22:52:31 +0200
Ahh, I see. There's a kernel exception handler that is supposed to fix
misaligned access? Hacky.
Not hacky, "transparent". It allows us to fast-path everything.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ARM: Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 21:03 ` Russell King
@ 2001-12-18 21:11 ` David S. Miller
2001-12-18 21:14 ` Russell King
2001-12-18 21:24 ` Rik van Riel
0 siblings, 2 replies; 22+ messages in thread
From: David S. Miller @ 2001-12-18 21:11 UTC (permalink / raw)
To: rmk; +Cc: kuznet, Mika.Liljeberg, Mika.Liljeberg, linux-kernel, sarolaht
From: Russell King <rmk@arm.linux.org.uk>
Date: Tue, 18 Dec 2001 21:03:32 +0000
On Tue, Dec 18, 2001 at 11:29:06PM +0300, kuznet@ms2.inr.ac.ru wrote:
> No doubts it still has broken misaligned access.
You're way out of line with that comment.
Not necessarily Russell. You have even told us on several occaisions
that the older ARMs simply cannot fix up unaligned loads/stores in
fact.
Look, we're analyzing a problem and trying to explore every avenue
for possible problems. If this were sparc64 I'd be checking my
unaligned handler for bugs :-)
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ARM: Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 21:11 ` David S. Miller
@ 2001-12-18 21:14 ` Russell King
2001-12-18 21:15 ` David S. Miller
2001-12-18 21:24 ` Rik van Riel
1 sibling, 1 reply; 22+ messages in thread
From: Russell King @ 2001-12-18 21:14 UTC (permalink / raw)
To: David S. Miller
Cc: kuznet, Mika.Liljeberg, Mika.Liljeberg, linux-kernel, sarolaht
On Tue, Dec 18, 2001 at 01:11:55PM -0800, David S. Miller wrote:
> On Tue, Dec 18, 2001 at 11:29:06PM +0300, kuznet@ms2.inr.ac.ru wrote:
> > No doubts it still has broken misaligned access.
>
> You're way out of line with that comment.
>
> Not necessarily Russell. You have even told us on several occaisions
> that the older ARMs simply cannot fix up unaligned loads/stores in
> fact.
It read as "Oh, it's ARM, that's your problem then".
> Look, we're analyzing a problem and trying to explore every avenue
> for possible problems. If this were sparc64 I'd be checking my
> unaligned handler for bugs :-)
Well, as its already been established, its not running Linux, so it's not
my problem. 8)
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ARM: Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 21:14 ` Russell King
@ 2001-12-18 21:15 ` David S. Miller
2001-12-18 21:27 ` Mika Liljeberg
0 siblings, 1 reply; 22+ messages in thread
From: David S. Miller @ 2001-12-18 21:15 UTC (permalink / raw)
To: rmk; +Cc: kuznet, Mika.Liljeberg, Mika.Liljeberg, linux-kernel, sarolaht
From: Russell King <rmk@arm.linux.org.uk>
Date: Tue, 18 Dec 2001 21:14:50 +0000
On Tue, Dec 18, 2001 at 01:11:55PM -0800, David S. Miller wrote:
> On Tue, Dec 18, 2001 at 11:29:06PM +0300, kuznet@ms2.inr.ac.ru wrote:
> > No doubts it still has broken misaligned access.
>
> You're way out of line with that comment.
>
> Not necessarily Russell. You have even told us on several occaisions
> that the older ARMs simply cannot fix up unaligned loads/stores in
> fact.
It read as "Oh, it's ARM, that's your problem then".
If it was "your problem, so go away" why did I even bother posting a
patch for him to test out?
Franks a lot,
David S. Miller
davem@redhat.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ARM: Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 21:11 ` David S. Miller
2001-12-18 21:14 ` Russell King
@ 2001-12-18 21:24 ` Rik van Riel
2001-12-18 21:28 ` Russell King
2001-12-18 21:33 ` David S. Miller
1 sibling, 2 replies; 22+ messages in thread
From: Rik van Riel @ 2001-12-18 21:24 UTC (permalink / raw)
To: David S. Miller
Cc: rmk, kuznet, Mika.Liljeberg, Mika.Liljeberg, linux-kernel,
sarolaht
On Tue, 18 Dec 2001, David S. Miller wrote:
> From: Russell King <rmk@arm.linux.org.uk>
> On Tue, Dec 18, 2001 at 11:29:06PM +0300, kuznet@ms2.inr.ac.ru wrote:
> > No doubts it still has broken misaligned access.
>
> You're way out of line with that comment.
>
> Not necessarily Russell. You have even told us on several occaisions
> that the older ARMs simply cannot fix up unaligned loads/stores in
> fact.
Then the problem will have to be fixed elsewhere, maybe
by having the networking code do explicit unaligned
accesses through some macro which defaults to a normal
access on other systems ?
> Look, we're analyzing a problem and trying to explore every avenue for
> possible problems. If this were sparc64 I'd be checking my unaligned
> handler for bugs :-)
If sparc64 had this hardware problems, I'm sure we'd have
special hacks to handle the situation all throughout the
kernel already, instead of having such hacks blocked by
subsystem maintainers.
cheers,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ARM: Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 21:15 ` David S. Miller
@ 2001-12-18 21:27 ` Mika Liljeberg
0 siblings, 0 replies; 22+ messages in thread
From: Mika Liljeberg @ 2001-12-18 21:27 UTC (permalink / raw)
To: David S. Miller; +Cc: rmk, kuznet, Mika.Liljeberg, linux-kernel, sarolaht
"David S. Miller" wrote:
> If it was "your problem, so go away" why did I even bother posting a
> patch for him to test out?
Whoa, chill fellas! I didn't mean to start a flame war. :-|
I'll give your patch a go, although seeing that the platform takes care
of the alignment problem, the real bug is probably elsewhere.
MikaL
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ARM: Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 21:24 ` Rik van Riel
@ 2001-12-18 21:28 ` Russell King
2001-12-18 21:33 ` David S. Miller
1 sibling, 0 replies; 22+ messages in thread
From: Russell King @ 2001-12-18 21:28 UTC (permalink / raw)
To: Rik van Riel
Cc: David S. Miller, kuznet, Mika.Liljeberg, Mika.Liljeberg,
linux-kernel, sarolaht
On Tue, Dec 18, 2001 at 07:24:41PM -0200, Rik van Riel wrote:
> On Tue, 18 Dec 2001, David S. Miller wrote:
> > Not necessarily Russell. You have even told us on several occaisions
> > that the older ARMs simply cannot fix up unaligned loads/stores in
> > fact.
>
> Then the problem will have to be fixed elsewhere, maybe
> by having the networking code do explicit unaligned
> accesses through some macro which defaults to a normal
> access on other systems ?
It's actually not worth it; these "older ARMs" I believe we can safely
drop from our sights - it has been my intention throughout 2.4 to drop
them out when 2.5 came around. The problem is that there are people
who do want still use antequated machines, but they can look after
the problems that entails themselves IMHO. 8)
So, as far as 2.5 is concerned, consider all ARMs capable of handling
mis-aligned accesses via a fault handler.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ARM: Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 21:24 ` Rik van Riel
2001-12-18 21:28 ` Russell King
@ 2001-12-18 21:33 ` David S. Miller
1 sibling, 0 replies; 22+ messages in thread
From: David S. Miller @ 2001-12-18 21:33 UTC (permalink / raw)
To: riel; +Cc: rmk, kuznet, Mika.Liljeberg, Mika.Liljeberg, linux-kernel,
sarolaht
From: Rik van Riel <riel@conectiva.com.br>
Date: Tue, 18 Dec 2001 19:24:41 -0200 (BRST)
Then the problem will have to be fixed elsewhere, maybe
by having the networking code do explicit unaligned
accesses through some macro which defaults to a normal
access on other systems ?
It is a port requirement to fix up such accesses. It has always been
a port requirement to fix up such accesses, and it isn't going to
change.
If I fix up TCP options, I'd have to fixup every access to every
single networking header in the entire stack because "protocol in
protocol" cases can cause unaligned accesses to happen just about any
place.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-18 20:21 ` Mika Liljeberg
2001-12-18 20:28 ` David S. Miller
2001-12-18 20:29 ` ARM: " kuznet
@ 2001-12-20 7:31 ` Stevie O
2001-12-20 7:40 ` David S. Miller
` (3 more replies)
2 siblings, 4 replies; 22+ messages in thread
From: Stevie O @ 2001-12-20 7:31 UTC (permalink / raw)
To: David S. Miller, Mika.Liljeberg
Cc: kuznet, Mika.Liljeberg, linux-kernel, sarolaht
At 12:28 PM 12/18/2001 -0800, David S. Miller wrote:
>Unaligned kernel loads and stores must be properly handled by the
>platform code, and on ARM chips where that is possible it is.
I don't know what arch you're using, but I work with ARM7TDMI, which has a
behavior I believe can be found documented in some obscure .pdf from arm.com:
Unaligned accesses wrap.
If you have this:
[mem.] 00 01 02 03 04 05 06 07
[data] 00 11 22 33 44 55 66 77
in little-endian mode,
*(int*)0x00 == 0x33221100
*(int*)0x01 == 0x00332211
*(int*)0x02 == 0x11003322
*(int*)0x03 == 0x22110033
*(int*)0x04 == 0x77665544
At least, that's how ARM's docs seem to describe it. I work with this cpu
embedded in a microcontroller (AT91M40800), and these values result:
*(int*)0x00 == 0x33221100
*(int*)0x01 == 0x33221100
*(int*)0x02 == 0x33221100
*(int*)0x03 == 0x33221100
*(int*)0x04 == 0x77665544
An unaligned access to an assembly-declared variable caused me much grief
once, overwriting the task scheduler's ready-to-run list under certain
conditions...
The moral of the story:
RISC cpus abhor unaligned accesses.
--
Stevie-O
Real programmers use COPY CON PROGRAM.EXE
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-20 7:31 ` Stevie O
@ 2001-12-20 7:40 ` David S. Miller
2001-12-20 7:51 ` Stevie O
` (2 subsequent siblings)
3 siblings, 0 replies; 22+ messages in thread
From: David S. Miller @ 2001-12-20 7:40 UTC (permalink / raw)
To: stevie; +Cc: Mika.Liljeberg, kuznet, Mika.Liljeberg, linux-kernel, sarolaht
From: Stevie O <stevie@qrpff.net>
Date: Thu, 20 Dec 2001 02:31:44 -0500
The moral of the story:
RISC cpus abhor unaligned accesses.
They should trap on it or handle it, silent "garbage" is really not
nice behavior.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-20 7:31 ` Stevie O
2001-12-20 7:40 ` David S. Miller
@ 2001-12-20 7:51 ` Stevie O
2001-12-20 8:58 ` Russell King
2001-12-20 9:01 ` Russell King
2001-12-20 10:22 ` David Weinehall
3 siblings, 1 reply; 22+ messages in thread
From: Stevie O @ 2001-12-20 7:51 UTC (permalink / raw)
To: David S. Miller
Cc: Mika.Liljeberg, kuznet, Mika.Liljeberg, linux-kernel, sarolaht
At 11:40 PM 12/19/2001 -0800, David S. Miller wrote:
>They should trap on it or handle it, silent "garbage" is really not
>nice behavior.
hah, I wish. The ARM7 has seven "exception" vectors -- that's it.
0x00 = RESET
0x04 = Undefined instruction
0x08 = Software interrupt (SWI instruction, used to escape the restricted
USR cpu mode)
0x0C = Data abort (a very very very much lesser form of an access
violation; accessing memory that's physically not there)
0x10 = Prefetch abort (a data abort that happens trying to read the next
instruction)
0x14 = IRQ <- these two can't really even count as exceptions!
0x18 = FIQ <- which makes for five...
0x1C = <-
0x20 = <- Oh, yeah, and two "reserved" fields which aren't likely to ever
be used.
Anyway, this is a bit off-topic now.
--
Stevie-O
Real programmers use COPY CON PROGRAM.EXE
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-20 7:51 ` Stevie O
@ 2001-12-20 8:58 ` Russell King
0 siblings, 0 replies; 22+ messages in thread
From: Russell King @ 2001-12-20 8:58 UTC (permalink / raw)
To: Stevie O
Cc: David S. Miller, Mika.Liljeberg, kuznet, Mika.Liljeberg,
linux-kernel, sarolaht
On Thu, Dec 20, 2001 at 02:51:42AM -0500, Stevie O wrote:
> hah, I wish. The ARM7 has seven "exception" vectors -- that's it.
If you're running on a processor without CP#15 register 1, and therefore
doesn't have the alignment data abort trap (eg, MMUless ARMs), then you're
on your own.
If you do have it, and you didn't enable the alignment fault handler,
that's your problem as well.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-20 7:31 ` Stevie O
2001-12-20 7:40 ` David S. Miller
2001-12-20 7:51 ` Stevie O
@ 2001-12-20 9:01 ` Russell King
2001-12-20 10:22 ` David Weinehall
3 siblings, 0 replies; 22+ messages in thread
From: Russell King @ 2001-12-20 9:01 UTC (permalink / raw)
To: Stevie O
Cc: David S. Miller, Mika.Liljeberg, kuznet, Mika.Liljeberg,
linux-kernel, sarolaht
On Thu, Dec 20, 2001 at 02:31:44AM -0500, Stevie O wrote:
> I don't know what arch you're using, but I work with ARM7TDMI, which has a
> behavior I believe can be found documented in some obscure .pdf from arm.com:
Sorry, it's not an obscure PDF. It's documented in the Architecture
Reference Manual, which is the main reference for the behaviour of any
ARM processor. If you don't have that, then you're missing *vital*
information.
> At least, that's how ARM's docs seem to describe it. I work with this cpu
> embedded in a microcontroller (AT91M40800), and these values result:
>
> *(int*)0x00 == 0x33221100
> *(int*)0x01 == 0x33221100
> *(int*)0x02 == 0x33221100
> *(int*)0x03 == 0x33221100
> *(int*)0x04 == 0x77665544
Looks like some random manufacturer decided to do something different.
Nothing out of the ordinary there. 8(
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-20 7:31 ` Stevie O
` (2 preceding siblings ...)
2001-12-20 9:01 ` Russell King
@ 2001-12-20 10:22 ` David Weinehall
2002-01-02 19:52 ` Mike Touloumtzis
3 siblings, 1 reply; 22+ messages in thread
From: David Weinehall @ 2001-12-20 10:22 UTC (permalink / raw)
To: Stevie O
Cc: David S. Miller, Mika.Liljeberg, kuznet, Mika.Liljeberg,
linux-kernel, sarolaht
On Thu, Dec 20, 2001 at 02:31:44AM -0500, Stevie O wrote:
> At 12:28 PM 12/18/2001 -0800, David S. Miller wrote:
> >Unaligned kernel loads and stores must be properly handled by the
> >platform code, and on ARM chips where that is possible it is.
>
> I don't know what arch you're using, but I work with ARM7TDMI, which
> has a behavior I believe can be found documented in some obscure .pdf
> from arm.com:
Last time I checked, the ARM7tdmi was a mmu-less cpu -> ucLinux.
/David
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA]
2001-12-20 10:22 ` David Weinehall
@ 2002-01-02 19:52 ` Mike Touloumtzis
0 siblings, 0 replies; 22+ messages in thread
From: Mike Touloumtzis @ 2002-01-02 19:52 UTC (permalink / raw)
To: David Weinehall
Cc: Stevie O, David S. Miller, Mika.Liljeberg, kuznet, Mika.Liljeberg,
linux-kernel, sarolaht
On Thu, Dec 20, 2001 at 11:22:18AM +0100, David Weinehall wrote:
>
> Last time I checked, the ARM7tdmi was a mmu-less cpu -> ucLinux.
The Cirrus Logic EP7211, among others, is an ARM7TDMI with an MMU.
miket
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2002-01-02 19:55 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-12-18 9:33 TCP LAST-ACK state broken in 2.4.17-pre2 [NEW DATA] Mika.Liljeberg
2001-12-18 18:37 ` kuznet
2001-12-18 20:21 ` Mika Liljeberg
2001-12-18 20:28 ` David S. Miller
2001-12-18 20:29 ` ARM: " kuznet
2001-12-18 20:52 ` Mika Liljeberg
2001-12-18 21:08 ` David S. Miller
2001-12-18 21:03 ` Russell King
2001-12-18 21:11 ` David S. Miller
2001-12-18 21:14 ` Russell King
2001-12-18 21:15 ` David S. Miller
2001-12-18 21:27 ` Mika Liljeberg
2001-12-18 21:24 ` Rik van Riel
2001-12-18 21:28 ` Russell King
2001-12-18 21:33 ` David S. Miller
2001-12-20 7:31 ` Stevie O
2001-12-20 7:40 ` David S. Miller
2001-12-20 7:51 ` Stevie O
2001-12-20 8:58 ` Russell King
2001-12-20 9:01 ` Russell King
2001-12-20 10:22 ` David Weinehall
2002-01-02 19:52 ` Mike Touloumtzis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox