[stable 4.4.y] ppp: defer netns reference release for ppp channel
Please apply the following patch to linux-stable 4.4.y: commit 205e1e255c479f3fd77446415706463b282f94e4 ppp: defer netns reference release for ppp channel This is already present in 4.8.y and fixes an issue with ppp channels that would otherwise cause a BUG() in ppp_pernet while a global ppp mutex is held, preventing further ppp connections from being established. The issue is reproducible by having pppd use a PPPoE server that closes new connections immediately (e.g. rp-pppoe "pppoe-server -q /bin/true"). -- Simon Arlott
[PATCH] bcm63xx_enet: check 1000BASE-T advertisement configuration
If a gigabit ethernet PHY is connected to a fast ethernet MAC,
then it can detect 1000 support from the partner but not use it.
This results in a forced speed of 1000 and RX/TX failure.
Check for 1000BASE-T support and then check the advertisement
configuration before setting the MAC speed to 1000mbit.
Signed-off-by: Simon Arlott <si...@fire.lp0.eu>
---
The BCM63168 has a gigabit ethernet PHY for one of the ports but only
a fast ethernet MAC as part of the enetsw interface.
The BCM63268 includes a configurable gigabit ethernet MAC with a
different interface "gmac" (this is a MIPS chip and it's not the same
interface as the ARM version).
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 33
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index a7f2cc3..4183c2a 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -2049,7 +2049,7 @@ static void swphy_poll_timer(unsigned long data)
for (i = 0; i < priv->num_ports; i++) {
struct bcm63xx_enetsw_port *port;
- int val, j, up, advertise, lpa, lpa2, speed, duplex, media;
+ int val, j, up, advertise, lpa, speed, duplex, media;
int external_phy = bcm_enet_port_is_rgmii(i);
u8 override;
@@ -2092,22 +2092,27 @@ static void swphy_poll_timer(unsigned long data)
lpa = bcmenet_sw_mdio_read(priv, external_phy, port->phy_id,
MII_LPA);
- lpa2 = bcmenet_sw_mdio_read(priv, external_phy, port->phy_id,
- MII_STAT1000);
-
/* figure out media and duplex from advertise and LPA values */
media = mii_nway_result(lpa & advertise);
duplex = (media & ADVERTISE_FULL) ? 1 : 0;
- if (lpa2 & LPA_1000FULL)
- duplex = 1;
-
- if (lpa2 & (LPA_1000FULL | LPA_1000HALF))
- speed = 1000;
- else {
- if (media & (ADVERTISE_100FULL | ADVERTISE_100HALF))
- speed = 100;
- else
- speed = 10;
+
+ if (media & (ADVERTISE_100FULL | ADVERTISE_100HALF))
+ speed = 100;
+ else
+ speed = 10;
+
+ if (val & BMSR_ESTATEN) {
+ advertise = bcmenet_sw_mdio_read(priv, external_phy,
+ port->phy_id, MII_CTRL1000);
+
+ lpa = bcmenet_sw_mdio_read(priv, external_phy,
+ port->phy_id, MII_STAT1000);
+
+ if (advertise & (ADVERTISE_1000FULL |
ADVERTISE_1000HALF)
+ && lpa & (LPA_1000FULL | LPA_1000HALF))
{
+ speed = 1000;
+ duplex = (lpa & LPA_1000FULL);
+ }
}
dev_info(>pdev->dev,
--
2.1.4
--
Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] solos-pci: Fix BUG() with shared skb
On Tue, September 15, 2015 20:10, David Woodhouse wrote:
> On Wed, 2013-09-04 at 21:41 +0100, David Woodhouse wrote:
>> +++ b/drivers/atm/solos-pci.c
>> @@ -1145,19 +1145,19 @@ static int psend(struct atm_vcc *vcc, struct sk_buff
>> *skb)
>> +> > if (skb_headroom(skb) < sizeof(*header)) {
>> +> > > struct sk_buff *nskb;
>> +
>> +> > > nskb = skb_realloc_headroom(skb, sizeof(*header));
>> +> > > if (!nskb) {
>> +> > > > solos_pop(vcc, skb);
>> +> > > > return -ENOMEM;
>> +> > > }
>> +> > > if (skb->truesize != nskb->truesize)
>> +> > > > atm_force_charge(vcc, nskb->truesize - skb->truesize);
>> +
>> +> > > dev_kfree_skb_any(skb);
>> +> > > skb = nskb;
>> > > }
>
> Simon, did you ever test this?
> Can you still (tell me how to) reproduce the original problem? I think
> that sending on br2684 was necessary but not sufficient...?
I'm currently using this but without the call to atm_force_charge().
I don't know how to reproduce the BUG() but it hasn't happened again.
--
Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
sockets affected by IPsec always block (2.6.23)
If I have a IPsec rule like:
spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
(i.e. a remote host 1.2.3.4 which will not respond)
Then any attempt to communicate with 1.2.3.4 will block, even when using
non-blocking sockets:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_LINGER, {onoff=1, linger=0}, 8) = 0
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 -- non-blocking socket
connect(3, {sa_family=AF_INET, sin_port=htons(22),
sin_addr=inet_addr(1.2.3.4)}, 16 -- blocked connect()
[277657.564773] netcatS b06bcf20 0 9450 9449
[277657.564785]c8d51d28 00200046 00200046 b06bcf20 00200286 c8d51d14
00200286 c8d51d84
[277657.564814]b06bcf20 c8d51d28 b013680b c8d51d84 eeae8800 c8d51d78
c8d51dd0 b04d3fc5
[277657.564843]c8d51da4 0002 0001 ede87284 0002 0040
e9318ac0 db3f20a0
[277657.564874] Call Trace:
[277657.564881] [b04d3fc5] __xfrm_lookup+0x2f5/0x510
[277657.564905] [b0494f9e] ip_route_output_flow+0x4e/0x80
[277657.564919] [b04af303] tcp_v4_connect+0x183/0x6d0
[277657.564934] [b04beaf2] inet_stream_connect+0x122/0x1c0
[277657.564949] [b0471c8e] sys_connect+0x9e/0xd0
[277657.564963] [b0472785] sys_socketcall+0xa5/0x230
[277657.564973] [b01042ba] syscall_call+0x7/0xb
[277657.564984] ===
I had a process using non-blocking sockets stuck in connect() for over 8 hours
because of this...
2630 __xfrm_lookup:
...
290b: b8 00 00 00 00 mov$0x0,%eax
290c: R_386_32 km_waitq
2910: e8 fc ff ff ff call 2911 __xfrm_lookup+0x2e1
2911: R_386_PC32add_wait_queue
2915: a1 00 00 00 00 mov0x0,%eax
2916: R_386_32 per_cpu__current_task
291a: c7 00 01 00 00 00 movl $0x1,(%eax)
2920: e8 fc ff ff ff call 2921 __xfrm_lookup+0x2f1
2921: R_386_PC32schedule
2925: a1 00 00 00 00 mov0x0,%eax
2926: R_386_32 per_cpu__current_task
292a: c7 00 00 00 00 00 movl $0x0,(%eax)
2930: b8 00 00 00 00 mov$0x0,%eax
2931: R_386_32 km_waitq
2935: 89 da mov%ebx,%edx
2937: e8 fc ff ff ff call 2938 __xfrm_lookup+0x308
2938: R_386_PC32remove_wait_queue
--
Simon Arlott
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
. [ 23.251680] PNP: No PS/2 controller found. Probing ports directly. [ 23.506189] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 23.511290] mice: PS/2 mouse device common for all mice [ 23.516687] i2c /dev entries driver [ 23.520501] f71805f: Found F71805F/FG chip at 0x290, revision 19 [ 23.918166] device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [EMAIL PROTECTED] [ 23.926741] padlock: Using VIA PadLock ACE for AES algorithm. [ 23.932501] padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms. [ 23.939102] Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC). [ 23.948323] ACPI: PCI Interrupt :00:11.5[C] - Link [LNKC] - GSI 10 (level, low) - IRQ 10 [ 23.957225] PCI: Setting latency timer of device :00:11.5 to 64 [ 24.471419] ALSA device list: [ 24.474442] #0: VIA 8237 with ALC655 at 0xf400, irq 10 [ 24.479813] Netfilter messages via NETLINK v0.30. [ 24.484642] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 24.490812] ctnetlink v0.93: registering with nfnetlink. [ 24.496178] IPv4 over IPv4 tunneling driver [ 24.500581] GRE over IPv4 tunneling driver [ 24.505138] ip_tables: (C) 2000-2006 Netfilter Core Team [ 24.510561] ClusterIP Version 0.8 loaded successfully [ 24.515629] TCP bic registered [ 24.518695] TCP cubic registered [ 24.521934] TCP westwood registered [ 24.525431] TCP highspeed registered [ 24.529001] TCP hybla registered [ 24.532243] TCP htcp registered [ 24.535398] TCP vegas registered [ 24.538639] TCP veno registered [ 24.541790] TCP scalable registered [ 24.545287] TCP lp registered [ 24.548251] TCP yeah registered [ 24.551407] TCP illinois registered [ 24.554907] Initializing XFRM netlink socket [ 24.559235] NET: Registered protocol family 1 [ 24.563686] NET: Registered protocol family 10 [ 24.568252] lo: Disabled Privacy Extensions [ 24.572570] tunl0: Disabled Privacy Extensions [ 24.577102] Mobile IPv6 [ 24.579595] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 24.585041] IPv6 over IPv4 tunneling driver [ 24.589473] sit0: Disabled Privacy Extensions [ 24.593998] NET: Registered protocol family 17 [ 24.598469] NET: Registered protocol family 15 [ 24.602979] Bridge firewalling registered [ 24.607005] Ebtables v2.0 registered [ 24.610618] 802.1Q VLAN Support v1.8 Ben Greear [EMAIL PROTECTED] [ 24.617408] All bugs added by David S. Miller [EMAIL PROTECTED] [ 24.623704] CPU0 - ACPI performance management activated. [ 24.629116] *P0: 1500 MHz, 15000 mW, 10 µs [ 24.633742] P1: 800 MHz, 8000 mW, 10 µs [ 24.638582] Using IPI Shortcut mode [ 24.689701] kjournald starting. Commit interval 5 seconds [ 24.695233] EXT3-fs: mounted filesystem with ordered data mode. [ 24.701177] VFS: Mounted root (ext3 filesystem) readonly. [ 24.706864] Freeing unused kernel memory: 184k freed [ 24.712029] Write protecting the kernel text: 2596k [ 24.716975] Write protecting the kernel read-only data: 926k -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/05] ipv6: RFC4214 Support
On 07/11/07 18:52, Templin, Fred L wrote: +eui[0] = 0; + +/* Check for RFC3330 global address ranges */ +if (((ipv4 = 0x0100) (ipv4 0x0a00)) || +((ipv4 = 0x0b00) (ipv4 0x7f00)) || +((ipv4 = 0x8000) (ipv4 0xa9fe)) || +((ipv4 = 0xa9ff) (ipv4 0xac10)) || +((ipv4 = 0xac20) (ipv4 0xc0a8)) || +((ipv4 = 0xc0a9) (ipv4 0xc612)) || +((ipv4 = 0xc614) (ipv4 0xe000))) eui[0] |= 0x2; I don't understand. For example, 1.0.0.11 is valid IPv4 global address. In little-endian, this is not in the range of 0x0001 = addr = 0x000a (addr is 0x0b01). Maybe it is I who did not understand. Can you suggest a clean solution? ((ipv4 htonl(0xFF00)) == htonl(0x0A00)) etc.? -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/05] ipv6: RFC4214 Support
On 07/11/07 19:32, Templin, Fred L wrote: -Original Message- From: Simon Arlott [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 11:02 AM To: Templin, Fred L Cc: YOSHIFUJI Hideaki / 吉藤英明; [EMAIL PROTECTED]; netdev@vger.kernel.org Subject: Re: [PATCH 02/05] ipv6: RFC4214 Support On 07/11/07 18:52, Templin, Fred L wrote: + eui[0] = 0; + + /* Check for RFC3330 global address ranges */ + if (((ipv4 = 0x0100) (ipv4 0x0a00)) || + ((ipv4 = 0x0b00) (ipv4 0x7f00)) || + ((ipv4 = 0x8000) (ipv4 0xa9fe)) || + ((ipv4 = 0xa9ff) (ipv4 0xac10)) || + ((ipv4 = 0xac20) (ipv4 0xc0a8)) || + ((ipv4 = 0xc0a9) (ipv4 0xc612)) || + ((ipv4 = 0xc614) (ipv4 0xe000))) eui[0] |= 0x2; I don't understand. For example, 1.0.0.11 is valid IPv4 global address. In little-endian, this is not in the range of 0x0001 = addr = 0x000a (addr is 0x0b01). Maybe it is I who did not understand. Can you suggest a clean solution? ((ipv4 htonl(0xFF00)) == htonl(0x0A00)) etc.? I'm not sure this works when we consider disjoint ranges of globally-unique IP prefixes. Do you have a vision for how the entire conditional would look like? You need to match RFC3330 addresses, not anything that isn't. ((ipv4 htonl(0xFF00)) == htonl(0x0A00)) || ((ipv4 htonl(0x)) == htonl(0xC0A8)) || ((ipv4 htonl(0xFF00)) == htonl(0x8000)) etc. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 doesn't resume properly from standby (2.6.23-rc2)
On 06/08/07 04:01, Kok, Auke wrote: Simon Arlott wrote: 00:0a.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corp.: Unknown device 1012 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 5 Memory at e302 (64-bit, non-prefetchable) [size=128K] I/O ports at b000 [size=64] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device. Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- 00:0a.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corp.: Unknown device 1012 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 12 Memory at e300 (64-bit, non-prefetchable) [size=128K] I/O ports at b400 [size=64] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device. Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- [ 950.132046] Stopping tasks ... done. [ 950.459794] Suspending console(s) [ 951.776277] pnp: Device 00:0c disabled. [ 951.776673] pnp: Device 00:0a disabled. [ 951.776984] pnp: Device 00:09 disabled. [ 951.777306] pnp: Device 00:08 disabled. [ 951.86] ACPI: PCI interrupt for device :00:11.5 disabled [ 951.995359] ACPI: PCI interrupt for device :00:11.3 disabled [ 952.006094] ACPI: PCI interrupt for device :00:11.2 disabled [ 952.022243] ACPI handle has no context! [ 952.033068] ACPI: PCI interrupt for device :00:0c.2 disabled [ 952.044086] ACPI: PCI interrupt for device :00:0c.1 disabled [ 952.055083] ACPI: PCI interrupt for device :00:0c.0 disabled [ 952.282211] ACPI: PCI interrupt for device :00:0a.1 disabled [ 952.282221] ACPI handle has no context! [ 952.537474] ACPI: PCI interrupt for device :00:0a.0 disabled [ 952.537495] ACPI handle has no context! [ 956.857085] Back to C! [ 957.295035] ACPI: Unable to turn cooling device [b18d0e00] 'off' [ 957.521400] PCI: Setting latency timer of device :00:01.0 to 64 [ 957.521478] ACPI: PCI Interrupt :00:09.0[A] - Link [LNKB] - GSI 11 (level, low) - IRQ 11 [ 957.532256] PM: Writing back config space on device :00:0a.0 at offset f (was ff0100, writing ff0105) [ 957.532277] PM: Writing back config space on device :00:0a.0 at offset 8 (was 1, writing b001) [ 957.532291] PM: Writing back config space on device :00:0a.0 at offset 4 (was 4, writing e3020004) [ 957.532299] PM: Writing back config space on device :00:0a.0 at offset 3 (was 80, writing 802008) [ 957.532309] PM: Writing back config space on device :00:0a.0 at offset 1 (was 230, writing 237) [ 957.532339] ACPI: PCI Interrupt :00:0a.0[A] - Link [LNKC] - GSI 5 (level, low) - IRQ 5 [ 957.567251] PM: Writing back config space on device :00:0a.1 at offset f (was ff0200, writing ff020c) [ 957.567275] PM: Writing back config space on device :00:0a.1 at offset 8 (was 1, writing b401) [ 957.567290] PM: Writing back config space on device :00:0a.1 at offset 4 (was 4, writing e304) [ 957.567298] PM: Writing back config space on device :00:0a.1 at offset 3 (was 80, writing 802008) [ 957.567308] PM: Writing back config space on device :00:0a.1 at offset 1 (was 230, writing 237) [ 957.567346] ACPI: PCI Interrupt :00:0a.1[B] - Link [LNKD] - GSI 12 (level, low) - IRQ 12 [ 957.589975] ACPI: PCI Interrupt :00:0b.0[A] - Link [LNKD] - GSI 12 (level, low) - IRQ 12 [ 957.600217] ACPI: PCI Interrupt :00:0c.0[A] - Link [LNKA] - GSI 11 (level, low) - IRQ 11 [ 957.611230] ACPI: PCI Interrupt :00:0c.1[B] - Link [LNKB] - GSI 11 (level, low) - IRQ 11 [ 957.838282] ACPI: PCI Interrupt :00:0c.2[C] - Link [LNKC] - GSI 5 (level, low) - IRQ 5 [ 957.902166] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[11] MMIO=[e3046000-e30467ff] Max Packet=[512] IR/IT contexts=[4/8] [ 957.911656] ACPI: PCI Interrupt :00:11.1[A] - Link [LNKA] - GSI 11 (level, low) - IRQ 11 [ 957.911666] PCI: VIA VLink IRQ fixup for :00:11.1, from 255 to 11 [ 957.922034] ACPI: PCI Interrupt :00:11.2[D] - Link [LNKD] - GSI 12 (level, low) - IRQ 12 [ 957.933028] ACPI: PCI Interrupt :00:11.3[D] - Link [LNKD] - GSI 12 (level, low) - IRQ 12 [ 957.944076] ACPI: PCI Interrupt :00:11.5[C] - Link [LNKC] - GSI 5 (level, low) - IRQ 5 [ 957.944091] PCI: Setting latency timer of device :00:11.5 to 64 [ 957.946061] ACPI: PCI Interrupt :01:00.0[A] - Link [LNKA] - GSI 11 (level, low) - IRQ 11 [ 957.947464] pnp: Device 00:08 activated. [ 957.948724] pnp: Device 00:09 activated. [ 957.950635] pnp: Device 00:0a activated. [ 957.950664] pnp: Failed to activate device 00:0b. [ 957.951942] pnp: Device 00:0c activated. [ 959.883939] e1000
Re: e1000 doesn't resume properly from standby (2.6.23-rc2)
On Mon, August 6, 2007 11:44, Pavel Machek wrote: Hi! 00:0a.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corp.: Unknown device 1012 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 5 Memory at e302 (64-bit, non-prefetchable) [size=128K] I/O ports at b000 [size=64] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device. Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- 00:0a.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corp.: Unknown device 1012 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 12 Memory at e300 (64-bit, non-prefetchable) [size=128K] I/O ports at b400 [size=64] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device. Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- [ 950.132046] Stopping tasks ... done. [ 950.459794] Suspending console(s) [ 951.776277] pnp: Device 00:0c disabled. [ 951.776673] pnp: Device 00:0a disabled. [ 951.776984] pnp: Device 00:09 disabled. [ 951.777306] pnp: Device 00:08 disabled. [ 951.86] ACPI: PCI interrupt for device :00:11.5 disabled [ 951.995359] ACPI: PCI interrupt for device :00:11.3 disabled [ 952.006094] ACPI: PCI interrupt for device :00:11.2 disabled [ 952.022243] ACPI handle has no context! [ 952.033068] ACPI: PCI interrupt for device :00:0c.2 disabled [ 952.044086] ACPI: PCI interrupt for device :00:0c.1 disabled [ 952.055083] ACPI: PCI interrupt for device :00:0c.0 disabled [ 952.282211] ACPI: PCI interrupt for device :00:0a.1 disabled [ 952.282221] ACPI handle has no context! [ 952.537474] ACPI: PCI interrupt for device :00:0a.0 disabled [ 952.537495] ACPI handle has no context! [ 956.857085] Back to C! Are you sure that is standby? Looks like suspend-to-RAM to me. It's S1 (power-on suspend/standby), my BIOS/motherboard doesn't support S2 or S3. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
e1000 doesn't resume properly from standby (2.6.23-rc2)
[ 965.310493] hdg: selected mode 0x45 [ 965.316152] hdh: selected mode 0x42 [ 969.135523] hda: selected mode 0x46 [ 973.454631] hdb: selected mode 0x45 [ 973.457179] hdc: selected mode 0x44 [ 973.459550] hdd: selected mode 0x42 [ 973.950474] Restarting tasks ... done. [ 974.261357] agpgart: Found an AGP 2.0 compliant device at :00:00.0. [ 974.262099] agpgart: Putting AGP V2 device at :00:00.0 into 4x mode [ 974.262620] agpgart: Putting AGP V2 device at :01:00.0 into 4x mode [ 974.262894] [drm] Loading R200 Microcode eth0 now doesn't receive anything - it's transmitting ok because I can receive its packets on another host. It's also still getting interrupts. If I then ifconfig eth0 down and up, or change the MTU (since that resets the link on e1000), it starts working again: [ 993.926603] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX There's a link up at 959.883939 too... -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange tcp behavior
On 03/08/07 13:09, Evgeniy Polyakov wrote:
On Fri, Aug 03, 2007 at 01:03:46PM +0100, Simon Arlott ([EMAIL PROTECTED])
wrote:
On Fri, August 3, 2007 12:56, Evgeniy Polyakov wrote:
On Fri, Aug 03, 2007 at 12:21:46PM +0100, Simon Arlott ([EMAIL PROTECTED])
wrote:
Since the connection is considered closed, couldn't another socket re-use
it?
Socket A: Recv data (unread)
Socket A: Recv RST
Socket B: Reuses connection (same IPs/ports)
Socket A: Close
Wouldn't that disrupt socket B's use of the connection?
Then it will drop our data, since there were no appropriate handhsake.
Couldn't the sequence numbers be close enough to make the RST valid?
It does not matter - if connection is not in synchronized state all
unrelated data is dropped, so remote side is only allowed to receive syn
flag only, anything else must be dropped. If remote side does not do
that, it violates RFC.
Except the remote side has a connection, because another one can be made
before the existing connection is closed:
17:37:37.377571 IP 192.168.7.4.50550 192.168.7.8.2500: S
134077329:134077329(0) win 1500 (raw)
17:37:37.382352 IP 192.168.7.8.2500 192.168.7.4.50550: S
3460060233:3460060233(0) ack 134077330 win 14360 mss 7180 (accept)
17:37:37.377966 IP 192.168.7.4.50550 192.168.7.8.2500: . ack 1 win 1500 (raw)
17:37:37.378128 IP 192.168.7.4.50550 192.168.7.8.2500: P 1:17(16) ack 1 win
1500 (raw)
17:37:37.378162 IP 192.168.7.8.2500 192.168.7.4.50550: . ack 17 win 14360
17:37:37.378131 IP 192.168.7.4.50550 192.168.7.8.2500: R
134077346:134077346(0) win 1500 (raw)
17:37:37.412709 IP 192.168.7.4.50550 192.168.7.8.2500: SWE
3257207813:3257207813(0) win 14280 mss 7140,sackOK,timestamp 3601441543
0,nop,wscale 5 (connect)
17:37:37.412785 IP 192.168.7.8.2500 192.168.7.4.50550: SE
3495384256:3495384256(0) ack 3257207814 win 14336 mss 7180,sackOK,timestamp
4294812905 3601441543,nop,wscale 6 (accept)
17:37:37.412960 IP 192.168.7.4.50550 192.168.7.8.2500: . ack 1 win 447
nop,nop,timestamp 3601441543 4294812905
17:37:38.383085 IP 192.168.7.8.2500 192.168.7.4.50550: R
4259643274:4259643274(0) ack 1171836829 win 14360 (close (previous connection))
17:37:47.417649 IP 192.168.7.8.2500 192.168.7.4.50550: F 1:1(0) ack 1 win 224
nop,nop,timestamp 4294822910 3601441543 (close)
17:37:47.417993 IP 192.168.7.4.50550 192.168.7.8.2500: F 1:1(0) ack 2 win 447
nop,nop,timestamp 3601444045 4294822910 (read returned)
17:37:47.418466 IP 192.168.7.8.2500 192.168.7.4.50550: . ack 2 win 224
nop,nop,timestamp 4294822911 3601444045
The second connection also modified the RST|ACK that was sent compared to no
second connection:
17:38:03.532703 IP 192.168.7.4.50550 192.168.7.8.2500: S 82517575:82517575(0)
win 1500 (raw)
17:38:03.532832 IP 192.168.7.8.2500 192.168.7.4.50550: S
3495449795:3495449795(0) ack 82517576 win 14360 mss 7180 (accept)
17:38:03.533388 IP 192.168.7.4.50550 192.168.7.8.2500: . ack 1 win 1500 (raw)
17:38:03.533457 IP 192.168.7.4.50550 192.168.7.8.2500: P 1:17(16) ack 1 win
1500 (raw)
17:38:03.533597 IP 192.168.7.8.2500 192.168.7.4.50550: . ack 17 win 14360
17:38:03.533589 IP 192.168.7.4.50550 192.168.7.8.2500: R 82517592:82517592(0)
win 1500 (raw)
17:38:04.536277 IP 192.168.7.8.2500 192.168.7.4.50550: R 1:1(0) ack 17 win
14360 (close)
17:38:04.536277 IP 192.168.7.8.2500 192.168.7.4.50550: R 1:1(0) ack 17 win
14360
vs
17:37:38.383085 IP 192.168.7.8.2500 192.168.7.4.50550: R
4259643274:4259643274(0) ack 1171836829 win 14360
What happened there ?
On the server, run tcptest-server.c, which waits for 1s on the first connection
then 10s on the second connection.
On the client, run:
iptables -I INPUT -i eth0 -p tcp --dport 50550 -j DROP; ./client; iptables -D
INPUT -i eth0 -p tcp --dport 50550 -j DROP; ./tcptest-client
(client.c from john's original email)
--
Simon Arlott
#include sys/types.h
#include sys/socket.h
#include arpa/inet.h
#include poll.h
#include fcntl.h
#define PORT 2500
#define xerror(str) do { perror(str); exit(1); } while (0)
int main(void) {
struct sockaddr_in sa;
int l, s, tmp;
int t = 0;
memset(sa, 0, sizeof(sa));
l = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
if (!l)
xerror(socket);
sa.sin_family = AF_INET;
sa.sin_addr.s_addr = htonl(INADDR_ANY);
sa.sin_port = htons(PORT);
tmp = 1;
setsockopt(l, SOL_SOCKET, SO_REUSEADDR, (char*)tmp, sizeof(tmp));
if (bind(l, (struct sockaddr*)sa, sizeof(sa)) != 0)
xerror(bind);
if (listen(l, 0) != 0)
xerror(listen);
printf(server %d ready...\n, getpid());
for (t = 1; t = 2; t++) {
s = accept(l, NULL, NULL);
switch (fork()) {
case -1:
xerror(fork);
break;
case 0:
switch (t) {
case 1:
printf(server %d accepted connection\n, getpid());
#if 0
tmp = fcntl(s, F_GETFL, 0);
if (fcntl(s, F_SETFL, tmp | O_NONBLOCK) != 0)
xerror(fcntl);
if (send(s, AAA, 7, 0) != 7)
xerror(send);
#endif
printf(server %d waiting for 1
Re: strange tcp behavior
On Fri, August 3, 2007 09:25, Evgeniy Polyakov wrote: On Thu, Aug 02, 2007 at 07:58:03PM +0100, Simon Arlott ([EMAIL PROTECTED]) wrote: 19:24:32.897071 IP 192.168.7.4.5 192.168.7.8.2500: S 705362199:705362199(0) win 1500 19:24:32.897211 IP 192.168.7.8.2500 192.168.7.4.5: S 4159455228:4159455228(0) ack 705362200 win 14360 mss 7180 19:24:32.920784 IP 192.168.7.4.5 192.168.7.8.2500: . ack 1 win 1500 19:24:32.921732 IP 192.168.7.4.5 192.168.7.8.2500: P 1:17(16) ack 1 win 1500 19:24:32.921795 IP 192.168.7.8.2500 192.168.7.4.5: . ack 17 win 14360 19:24:32.922881 IP 192.168.7.4.5 192.168.7.8.2500: R 705362216:705362216(0) win 1500 19:24:34.927717 IP 192.168.7.8.2500 192.168.7.4.5: R 1:1(0) ack 17 win 14360 According to RFC 793, the RST from .4 means that the connection is CLOSED. RFC 2525 - common tcp problems, says we should send RST in this case, although it does not specify should we send it if socket is in CLOSED state or not. Well, we send :) Even if tcp_send_active_reset() will check if socket is in CLOSED state and will not send data, but is still there, it will not be easily triggered though, but it can be possible. Since the connection is considered closed, couldn't another socket re-use it? Socket A: Recv data (unread) Socket A: Recv RST Socket B: Reuses connection (same IPs/ports) Socket A: Close Wouldn't that disrupt socket B's use of the connection? -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange tcp behavior
On Fri, August 3, 2007 12:56, Evgeniy Polyakov wrote: On Fri, Aug 03, 2007 at 12:21:46PM +0100, Simon Arlott ([EMAIL PROTECTED]) wrote: Since the connection is considered closed, couldn't another socket re-use it? Socket A: Recv data (unread) Socket A: Recv RST Socket B: Reuses connection (same IPs/ports) Socket A: Close Wouldn't that disrupt socket B's use of the connection? Then it will drop our data, since there were no appropriate handhsake. Couldn't the sequence numbers be close enough to make the RST valid? -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange tcp behavior
On 03/08/07 18:39, Evgeniy Polyakov wrote: On Fri, Aug 03, 2007 at 05:51:42PM +0100, Simon Arlott ([EMAIL PROTECTED]) wrote: 17:38:03.533589 IP 192.168.7.4.50550 192.168.7.8.2500: R 82517592:82517592(0) win 1500 (raw) vs 17:37:38.383085 IP 192.168.7.8.2500 192.168.7.4.50550: R 4259643274:4259643274(0) ack 1171836829 win 14360 What happened there ? Erm... you seem to have removed parts of my message in a way that doesn't make sense... On Fri, Aug 03, 2007 at 05:51:42PM +0100, Simon Arlott wrote: 17:38:04.536277 IP 192.168.7.8.2500 192.168.7.4.50550: R 1:1(0) ack 17 win 14360 vs 17:37:38.383085 IP 192.168.7.8.2500 192.168.7.4.50550: R 4259643274:4259643274(0) ack 1171836829 win 14360 What happened there ? The first one is the RST sent when the connection is close()d without reading, and the second one is the same RST but after other connection has been made on the same ports using a different socket. It is the same situation, which would happen if you will spam remote side with RST packets with arbitrary sequence number in hope that it will reset some connection. Isn't it still possible that the connection that got reset is left open (possibly for days) until another connection using the same ports is using roughly the same sequence numbers? -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange tcp behavior
On Thu, August 2, 2007 11:16, Evgeniy Polyakov wrote: On Thu, Aug 02, 2007 at 01:55:50PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: On Thu, Aug 02, 2007 at 09:19:06AM +0300, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: 1186035057.207629127.0.0.1 - 127.0.0.1TCP 5 smtp [SYN] Seq=0 Len=0 1186035057.207632127.0.0.1 - 127.0.0.1TCP smtp 5 [SYN, ACK] Seq=0 Ack=1 Win=32792 Len=0 MSS=16396 1186035057.207666127.0.0.1 - 127.0.0.1TCP 5 smtp [ACK] Seq=1 Ack=1 Win=1500 Len=0 1186035057.207699127.0.0.1 - 127.0.0.1SMTP Command: EHLO localhost 1186035057.207718127.0.0.1 - 127.0.0.1TCP smtp 5 [ACK] Seq=1 Ack=17 Win=32792 Len=0 1186035057.207736127.0.0.1 - 127.0.0.1TCP 5 smtp [RST] Seq=17 Len=0 1186035057.223934127.0.0.1 - 127.0.0.1TCP 33787 5 [RST, ACK] Seq=0 Ack=0 Win=32792 Len=0 Can someone please comment as to why, tcp stack sends rst packet from the wrong source port in this situation. Besides the fact, that test applications do not run if started not as root, I got this: And it actually does not initializes a session, since tird line below shows RST, but not ack. The same with sendmail smtp server (i.e. 25 port like in your server) and unmodified client. Please provide application which can trigger the issue and I will help to debug this issue. If it will help you to debug client, I can run tcpdump on public server (say 194.85.82.65, please tell me your source address) to collect dumps. Current code does not trigger the issue on my machines (and works not like was intended by you). Ugh, and code really looks horrible... I just got multiple RSTs instead of a connection too. The second RST looks like it's from another connection - and a RST for a RST is wrong... -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange tcp behavior
(Don't remove CC:s, don't top post) On Thu, August 2, 2007 11:16, Evgeniy Polyakov wrote: On Thu, Aug 02, 2007 at 01:55:50PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: On Thu, Aug 02, 2007 at 09:19:06AM +0300, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: 1186035057.207629127.0.0.1 - 127.0.0.1TCP 5 smtp [SYN] Seq=0 Len=0 1186035057.207632127.0.0.1 - 127.0.0.1TCP smtp 5 [SYN, ACK] Seq=0 Ack=1 Win=32792 Len=0 MSS=16396 1186035057.207666127.0.0.1 - 127.0.0.1TCP 5 smtp [ACK] Seq=1 Ack=1 Win=1500 Len=0 1186035057.207699127.0.0.1 - 127.0.0.1SMTP Command: EHLO localhost 1186035057.207718127.0.0.1 - 127.0.0.1TCP smtp 5 [ACK] Seq=1 Ack=17 Win=32792 Len=0 1186035057.207736127.0.0.1 - 127.0.0.1TCP 5 smtp [RST] Seq=17 Len=0 1186035057.223934127.0.0.1 - 127.0.0.1TCP 33787 5 [RST, ACK] Seq=0 Ack=0 Win=32792 Len=0 Can someone please comment as to why, tcp stack sends rst packet from the wrong source port in this situation. Besides the fact, that test applications do not run if started not as root, I got this: And it actually does not initializes a session, since tird line below shows RST, but not ack. The same with sendmail smtp server (i.e. 25 port like in your server) and unmodified client. Please provide application which can trigger the issue and I will help to debug this issue. If it will help you to debug client, I can run tcpdump on public server (say 194.85.82.65, please tell me your source address) to collect dumps. Current code does not trigger the issue on my machines (and works not like was intended by you). Ugh, and code really looks horrible... I just got multiple RSTs instead of a connection too. The second RST looks like it's from another connection - and a RST for a RST is wrong... On Thu, August 2, 2007 12:45, [EMAIL PROTECTED] wrote: you need to add iptables rule for this to work, or else the tcp resets connection too early because it does not know that something is listening on 5 port. iptables -I INPUT -p tcp --dport 5 -j DROP should do the job. You didn't mention this before. Without the server running: 13:02:23.314352 IP 127.0.0.1.5 127.0.0.1.2500: S 53123695:53123695(0) win 1500 13:02:23.314442 IP 127.0.0.1.2500 127.0.0.1.5: R 0:0(0) ack 53123696 win 0 13:02:25.906975 IP 127.0.0.1.3315 127.0.0.1.49197: P 1285306902:1285307318(416) ack 1267361915 win 1024 nop,nop,timestamp 3575709021 3575672670 13:02:25.907060 IP 127.0.0.1.49197 127.0.0.1.3315: . ack 416 win 1541 nop,nop,timestamp 3575709021 3575709021 With the server running: 13:05:55.234696 IP 127.0.0.1.5 127.0.0.1.2500: S 1960601450:1960601450(0) win 1500 13:05:55.234799 IP 127.0.0.1.2500 127.0.0.1.5: S 2171862150:2171862150(0) ack 1960601451 win 32792 mss 16396 13:05:55.238271 IP 127.0.0.1.5 127.0.0.1.2500: . ack 1 win 1500 13:05:55.240034 IP 127.0.0.1.5 127.0.0.1.2500: P 1:17(16) ack 1 win 1500 13:05:55.240132 IP 127.0.0.1.2500 127.0.0.1.5: . ack 17 win 32792 13:05:55.242251 IP 127.0.0.1.5 127.0.0.1.2500: R 1960601467:1960601467(0) win 1500 13:05:55.253884 IP 127.0.0.1.56434 127.0.0.1.5: R 2171862151:2171862151(0) ack 1960601467 win 32792 Weird. I resent your final RST a few times with a delay: 13:13:05.199275 IP 127.0.0.1.5 127.0.0.1.2500: S 83018811:83018811(0) win 1500 13:13:05.199378 IP 127.0.0.1.2500 127.0.0.1.5: S 2627922927:2627922927(0) ack 83018812 win 32792 mss 16396 13:13:05.203368 IP 127.0.0.1.5 127.0.0.1.2500: . ack 1 win 1500 13:13:05.205049 IP 127.0.0.1.5 127.0.0.1.2500: P 1:17(16) ack 1 win 1500 13:13:05.205173 IP 127.0.0.1.2500 127.0.0.1.5: . ack 17 win 32792 13:13:05.206463 IP 127.0.0.1.5 127.0.0.1.2500: R 83018828:83018828(0) win 1500 13:13:05.207656 IP 127.0.0.1.5 127.0.0.1.2500: R 83018828:83018828(0) win 1500 13:13:05.217664 IP 127.0.0.1.55271 127.0.0.1.5: R 2627922928:2627922928(0) ack 83018828 win 32792 13:13:05.510239 IP 127.0.0.1.5 127.0.0.1.2500: R 83018828:83018828(0) win 1500 13:13:05.511644 IP 127.0.0.1.5 127.0.0.1.2500: R 83018828:83018828(0) win 1500 13:13:05.512764 IP 127.0.0.1.5 127.0.0.1.2500: R 83018828:83018828(0) win 1500 I don't know where that extra RST is coming from. This test would be more convincing between two hosts, since your bizarre client is using raw sockets as root and could be doing anything. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange tcp behavior
On 02/08/07 13:15, Simon Arlott wrote: (Don't remove CC:s, don't top post) On Thu, August 2, 2007 11:16, Evgeniy Polyakov wrote: On Thu, Aug 02, 2007 at 01:55:50PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: On Thu, Aug 02, 2007 at 09:19:06AM +0300, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: 1186035057.207629127.0.0.1 - 127.0.0.1TCP 5 smtp [SYN] Seq=0 Len=0 1186035057.207632127.0.0.1 - 127.0.0.1TCP smtp 5 [SYN, ACK] Seq=0 Ack=1 Win=32792 Len=0 MSS=16396 1186035057.207666127.0.0.1 - 127.0.0.1TCP 5 smtp [ACK] Seq=1 Ack=1 Win=1500 Len=0 1186035057.207699127.0.0.1 - 127.0.0.1SMTP Command: EHLO localhost 1186035057.207718127.0.0.1 - 127.0.0.1TCP smtp 5 [ACK] Seq=1 Ack=17 Win=32792 Len=0 1186035057.207736127.0.0.1 - 127.0.0.1TCP 5 smtp [RST] Seq=17 Len=0 1186035057.223934127.0.0.1 - 127.0.0.1TCP 33787 5 [RST, ACK] Seq=0 Ack=0 Win=32792 Len=0 Can someone please comment as to why, tcp stack sends rst packet from the wrong source port in this situation. I don't know where that extra RST is coming from. This test would be more convincing between two hosts, since your bizarre client is using raw sockets as root and could be doing anything. Server 192.168.7.8 (2.6.23) Client 192.168.7.4 (2.6.20) 17:33:45.326246 IP 192.168.7.4.5 192.168.7.8.2500: S 1385353579:1385353579(0) win 1500 17:33:45.326418 IP 192.168.7.8.2500 192.168.7.4.5: S 1388203102:1388203102(0) ack 1385353580 win 14360 mss 7180 17:33:45.348833 IP 192.168.7.4.5 192.168.7.8.2500: . ack 1 win 1500 17:33:45.349977 IP 192.168.7.4.5 192.168.7.8.2500: P 1:17(16) ack 1 win 1500 17:33:45.350117 IP 192.168.7.8.2500 192.168.7.4.5: . ack 17 win 14360 17:33:45.351273 IP 192.168.7.4.5 192.168.7.8.2500: R 1385353596:1385353596(0) win 1500 17:33:45.360878 IP 192.168.7.8.48186 192.168.7.4.5: R 1388203103:1388203103(0) ack 1385353596 win 14360 Seems to be losing the source port information when it decides to send that final RST|ACK. It's going through the TCPAbortOnClose path: tcp_close: - tcp_set_state(sk, TCP_CLOSE) - inet_put_port(tcp_hashinfo, sk) Perhaps it's losing the port information here? - tcp_send_active_reset(sk, GFP_KERNEL) TCP_CLOSE socket is finished Should these two calls be the other way round? Also, I don't think it should be sending a RST after the other side has sent one - the connection no longer exists so there is nothing on the other side to reset. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange tcp behavior
On 02/08/07 19:08, Evgeniy Polyakov wrote:
On Thu, Aug 02, 2007 at 06:15:52PM +0100, Simon Arlott ([EMAIL PROTECTED])
wrote:
17:33:45.351273 IP 192.168.7.4.5 192.168.7.8.2500: R
1385353596:1385353596(0) win 1500
17:33:45.360878 IP 192.168.7.8.48186 192.168.7.4.5: R
1388203103:1388203103(0) ack 1385353596 win 14360
Problem is not in tcp_send_active_reset(), when socket is being released
it is already damaged.
Problem is that inet_autobind() function is called for socket, which is
already dead, but not yet completely - it smells bad (since it has its
port freed), but stil alive (accessible via send()), so for its last
word inet_sendmsg() tries to bind it again, and only after that time it
will be eventually closed and freed completely.
So, following patch fixes problem for me.
Another solution might not to release port until socket is being
released, but that can lead to performance degradation.
Correct me if sk_err can be reset.
19:24:32.897071 IP 192.168.7.4.5 192.168.7.8.2500: S
705362199:705362199(0) win 1500
19:24:32.897211 IP 192.168.7.8.2500 192.168.7.4.5: S
4159455228:4159455228(0) ack 705362200 win 14360 mss 7180
19:24:32.920784 IP 192.168.7.4.5 192.168.7.8.2500: . ack 1 win 1500
19:24:32.921732 IP 192.168.7.4.5 192.168.7.8.2500: P 1:17(16) ack 1 win
1500
19:24:32.921795 IP 192.168.7.8.2500 192.168.7.4.5: . ack 17 win 14360
19:24:32.922881 IP 192.168.7.4.5 192.168.7.8.2500: R
705362216:705362216(0) win 1500
19:24:34.927717 IP 192.168.7.8.2500 192.168.7.4.5: R 1:1(0) ack 17 win
14360
According to RFC 793, the RST from .4 means that the connection
is CLOSED.
Reset Processing
The receiver of a RST first validates it, then changes state. If the
receiver was in the LISTEN state, it ignores it. If the receiver was
in SYN-RECEIVED state and had previously been in the LISTEN state,
then the receiver returns to the LISTEN state, otherwise the receiver
aborts the connection and goes to the CLOSED state. If the receiver
was in any other state, it aborts the connection and advises the user
and goes to the CLOSED state.
So when the call to close() is made without reading:
Abort
Format: ABORT (local connection name)
This command causes all pending SENDs and RECEIVES to be
aborted, the TCB to be removed, and a special RESET message to
be sent to the TCP on the other side of the connection.
Isn't there no other side of the connection to send the RESET too?
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 06c08e5..6790b23 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -168,8 +169,14 @@ void inet_sock_destruct(struct sock *sk)
static int inet_autobind(struct sock *sk)
{
struct inet_sock *inet;
+
/* We may need to bind the socket. */
lock_sock(sk);
+ if (sk-sk_err) {
+ release_sock(sk);
+ return sk-sk_err;
+ }
+
inet = inet_sk(sk);
if (!inet-num) {
if (sk-sk_prot-get_port(sk, 0)) {
@@ -686,8 +703,11 @@ int inet_sendmsg(struct kiocb *iocb, struct socket
*sock, struct msghdr *msg,
struct sock *sk = sock-sk;
/* We may need to bind the socket. */
- if (!inet_sk(sk)-num inet_autobind(sk))
- return -EAGAIN;
+ if (!inet_sk(sk)-num) {
+ int err = inet_autobind(sk);
+ if (err)
+ return err;
+ }
return sk-sk_prot-sendmsg(iocb, sk, msg, size);
}
@@ -698,8 +718,11 @@ static ssize_t inet_sendpage(struct socket *sock, struct
page *page, int offset,
struct sock *sk = sock-sk;
/* We may need to bind the socket. */
- if (!inet_sk(sk)-num inet_autobind(sk))
- return -EAGAIN;
+ if (!inet_sk(sk)-num) {
+ int err = inet_autobind(sk);
+ if (err)
+ return err;
+ }
if (sk-sk_prot-sendpage)
return sk-sk_prot-sendpage(sk, page, offset, size, flags);
--
Simon Arlott
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8754] New: Kernel addrconf modifies MTU of non-kernel routes
On 15/07/07 10:29, Simon Arlott wrote: On 14/07/07 23:09, Andrew Morton wrote: On Sat, 14 Jul 2007 14:54:32 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8754 I have an MTU of 16110 set on eth0 on a network where the MTU is 1500 as set by RAs. One of the other hosts on the network has an MRU/MTU of 7200 so I have a specific route to it with this MTU. If I add the route early (i.e. on startup) before address autoconfiguration takes place, when the first RA is received the kernel changes the MTU on my route - this should not happen. This also happens whenever I change the MTU on eth0 - it will alter the MTU on routes *I* have added too. While this is valid behaviour for a new MTU that is too low for the route it is not for an MTU above the route. Changing the MTU also allows the next RA with MTU set changes non-kernel routes too problem to occur again. The problem seems to be that because the IPv6 code maintains its own MTU for each interface, which is set from RAs (router advertisements) and when the interface MTU is set (it's also improperly modifiable via sysctl when it shouldn't be, but that's another bug), it uses that to limit the MTU of every route. I propose that it should use the real interface MTU as the limit for non-kernel routes and the RA MTU for kernel routes. Since IPv6 routes (appear to) always have an MTU (IPv4 routes don't and hence inherit from the interface) this would have the side effect that a user-added route's automatically set MTU would not be lowered by the RA MTU. New user IPv6 routes without an explicit MTU should not have one set and use the RA MTU automatically. Is this ok? I'll send a patch to do this some time this week when I get around to it. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] forcedeth: mac address correct
On 27/07/07 04:33, Ayaz Abdulla wrote:
In older chipsets, the mac address was stored in reversed order.
However, in newer chipsets, the mac address is in correct order. This
patch takes those newer chipsets into account and does not rely on a
special bit setup by BIOS'.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
- if (txreg NVREG_TRANSMITPOLL_MAC_ADDR_REV) {
+ if ((txreg NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
+ (id-driver_data DEV_HAS_CORRECT_MACADDR) {
This will not compile.
--
Simon Arlott
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses
On 26/07/07 00:49, Dave Johnson wrote: ipv6_addr_type() doesn't check for 'Unique Local IPv6 Unicast Addresses' (RFC4193) and returns IPV6_ADDR_RESERVED for that range. + if ((st htonl(0xFE00)) == htonl(0xFC00)) + return (IPV6_ADDR_UNICAST | + IPV6_ADDR_SCOPE_TYPE(IPV6_ADDR_SCOPE_GLOBAL)); /* RFC 4193 */ But ULA's scope isn't global, shouldn't it be IPV6_ADDR_SCOPE_ORGLOCAL ? -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH [Bug 8756]] IPv6: Don't update ADVMSS on routes where the MTU is not also updated
The ADVMSS value was incorrectly updated for ALL routes when the MTU
is updated because it's outside the effect of the if statement's
condition.
Signed-off-by: Simon Arlott [EMAIL PROTECTED]
---
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8756
net/ipv6/route.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 919de68..55ea80f 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1983,9 +1983,10 @@ static int rt6_mtu_change_route(struct rt6_info *rt,
void *p_arg)
!dst_metric_locked(rt-u.dst, RTAX_MTU)
(dst_mtu(rt-u.dst) arg-mtu ||
(dst_mtu(rt-u.dst) arg-mtu
- dst_mtu(rt-u.dst) == idev-cnf.mtu6)))
+ dst_mtu(rt-u.dst) == idev-cnf.mtu6))) {
rt-u.dst.metrics[RTAX_MTU-1] = arg-mtu;
- rt-u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(arg-mtu);
+ rt-u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(arg-mtu);
+ }
return 0;
}
--
1.5.0.1
--
Simon Arlott
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8755] New: ip -6 route change behaves like ip -6 route add
On 16/07/07 14:01, Patrick McHardy wrote:
Simon Arlott wrote:
Changing an existing route:
# ip -6 r show 2002::/16
2002::/16 dev sit0 metric 1024 expires 4482618sec mtu 1480 advmss 7140
hoplimit 4294967295
# ip -6 r change 2002::/16 dev sit0 mtu 1280
RTNETLINK answers: File exists
The code looks like it would support it properly. Please add a
few printks to inet6_rtm_newaddr to find out what goes wrong.
Erm. It's routing configuration that's broken not address configuration
(ip doesn't even . Looking at route.c through to ip6_fib.c, it doesn't
support replacing routes at all.
$ grep NLM_F_ ipv4/fib_*.c ipv4/route.c ipv6/fib6_* ipv6/ip6_fib.c
ipv6/route.c
ipv4/fib_frontend.c:cfg-fc_nlflags = NLM_F_CREATE;
ipv4/fib_frontend.c:.fc_nlflags = NLM_F_CREATE | NLM_F_APPEND,
ipv4/fib_hash.c:if (cfg-fc_nlflags NLM_F_EXCL)
ipv4/fib_hash.c:if (cfg-fc_nlflags NLM_F_REPLACE) {
ipv4/fib_hash.c: cfg-fc_nlinfo,
NLM_F_REPLACE);
ipv4/fib_hash.c:if (!(cfg-fc_nlflags NLM_F_APPEND))
ipv4/fib_hash.c:if (!(cfg-fc_nlflags NLM_F_CREATE))
ipv4/fib_hash.c: NLM_F_MULTI)
0) {
ipv4/fib_trie.c:if (cfg-fc_nlflags NLM_F_EXCL)
ipv4/fib_trie.c:if (cfg-fc_nlflags NLM_F_REPLACE) {
ipv4/fib_trie.c:tb-tb_id,
cfg-fc_nlinfo, NLM_F_REPLACE);
ipv4/fib_trie.c:if (!(cfg-fc_nlflags NLM_F_APPEND))
ipv4/fib_trie.c:if (!(cfg-fc_nlflags NLM_F_CREATE))
ipv4/route.c:1, NLM_F_MULTI) = 0) {
ipv6/route.c:prefix, NLM_F_MULTI);
--
Simon Arlott
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Bugme-new] [Bug 8755] New: ip -6 route change behaves like ip -6 route add
On 16/07/07 14:01, Patrick McHardy wrote: Simon Arlott wrote: On 15/07/07 16:07, Patrick McHardy wrote: Adding a route using change: # ip -6 r change 2002::/17 dev sit0 mtu 1280 # ip -6 r show 2002::/17 2002::/17 dev sit0 metric 1024 expires 21334368sec mtu 1280 advmss 1220 hoplimit 4294967295 ^ This shouldn't be possible! That one will probably be impossible to fix since IPv6 has never checked for NLM_F_EXCL, doing to now might break things. NLM_F_EXCL isn't used: if (matches(*argv, add) == 0) return iproute_modify(RTM_NEWROUTE, NLM_F_CREATE|NLM_F_EXCL, if (matches(*argv, change) == 0 || strcmp(*argv, chg) == 0) return iproute_modify(RTM_NEWROUTE, NLM_F_REPLACE, if (matches(*argv, replace) == 0) return iproute_modify(RTM_NEWROUTE, NLM_F_CREATE|NLM_F_REPLACE, test only uses NLM_F_EXCL... I didn't even know that existed and it's not shown in help text. The code looks like it would support it properly. Please add a few printks to inet6_rtm_newaddr to find out what goes wrong. Ok. Compare it to ipv4 where change never adds - replace is change, or add. (Also, replace doesn't work for v6 either). IPv4 doesn't check any netlink flags, so I don't think that is correct. It looks like it works perfectly for add, change, and replace: # ip r add 2.0.0.0/32 dev lo # ip r change 3.0.0.0/32 dev lo RTNETLINK answers: No such file or directory # ip r replace 3.0.0.0/32 dev lo # ip r change 2.0.0.0/32 dev lo mtu 100 # ip r 3.0.0.0 dev lo scope link 2.0.0.0 dev lo scope link mtu 100 -- Simon Arlott smime.p7s Description: S/MIME Cryptographic Signature
Re: [Bugme-new] [Bug 8756] New: Route advmss copied to ALL routes when interface MTU changes
On 15/07/07 05:48, Andrew Morton wrote: On Sat, 14 Jul 2007 15:34:31 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8756 It is unclear which kernel version this applies to? Linus' 2.6 tree, as of Mon Jul 9 15:50:56 2007 -0700 For some reason it says Version: 2.5 on the email and Version: on the website... Summary: Route advmss copied to ALL routes when interface MTU changes Product: Networking Version: 2.5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: IPV6 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Steps to reproduce: 1. Have multiple network devices and routes for them with standard (low, i.e. 1500) MTUs and default ADVMSS (e.g. 1440) 2. Change the MTU on one of them to something high (e.g. 7200) 3. The ADVMSS is incorrectly set for ALL routes based on the new MTU of the interface that changed. Note: if addrconf is running then the ADVMSS will be reset on the next RA, so this will impede attempts to reproduce. # ip -6 r fe80::/64 dev sit0 metric 256 expires 4481744sec mtu 1480 advmss 1440 hoplimit 4294967295 fe80::/64 dev ppp0 metric 256 expires 19071345sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth0 metric 256 expires 19072430sec mtu 1500 advmss 1440 hoplimit 4294967295 default dev ppp0 metric 1024 expires 19071347sec mtu 1500 advmss 1440 hoplimit 4294967295 # ifconfig eth0 mtu 7200 # ip -6 r fe80::/64 dev sit0 metric 256 expires 4481732sec mtu 1480 advmss 7140 hoplimit 4294967295 -- wrong fe80::/64 dev ppp0 metric 256 expires 19071334sec mtu 1500 advmss 7140 hoplimit 4294967295 -- wrong fe80::/64 dev eth0 metric 256 expires 19072419sec mtu 7200 advmss 7140 hoplimit 4294967295 -- correct Explicitly setting the MTU on these other routes (although this is not possible without having to add another route due to bug 8755) automatically sets ADVMSS appropriately. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8754] New: Kernel addrconf modifies MTU of non-kernel routes
On 14/07/07 23:09, Andrew Morton wrote: On Sat, 14 Jul 2007 14:54:32 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8754 I have an MTU of 16110 set on eth0 on a network where the MTU is 1500 as set by RAs. One of the other hosts on the network has an MRU/MTU of 7200 so I have a specific route to it with this MTU. If I add the route early (i.e. on startup) before address autoconfiguration takes place, when the first RA is received the kernel changes the MTU on my route - this should not happen. This also happens whenever I change the MTU on eth0 - it will alter the MTU on routes *I* have added too. While this is valid behaviour for a new MTU that is too low for the route it is not for an MTU above the route. Changing the MTU also allows the next RA with MTU set changes non-kernel routes too problem to occur again. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8755] New: ip -6 route change behaves like ip -6 route add
On 15/07/07 16:07, Patrick McHardy wrote: Changing an existing route: # ip -6 r show 2002::/16 2002::/16 dev sit0 metric 1024 expires 4482618sec mtu 1480 advmss 7140 hoplimit 4294967295 # ip -6 r change 2002::/16 dev sit0 mtu 1280 RTNETLINK answers: File exists ^ This is clearly a bug, since I'm trying to change an existing route and it gives an error as if it tried to add it. Adding a route using change: # ip -6 r change 2002::/17 dev sit0 mtu 1280 # ip -6 r show 2002::/17 2002::/17 dev sit0 metric 1024 expires 21334368sec mtu 1280 advmss 1220 hoplimit 4294967295 ^ This shouldn't be possible! There is a difference between add and change. add will only add a new address if there isn't already one with the same identity, change will allow to change attributes of an existing address, like flags, lifetime, ..., or behave similar to add in case the address doesn't already exist. What kind of behaviour are you expecting? That change would actually change not simply add. It won't let me change anything and in fact can only add instead. Compare it to ipv4 where change never adds - replace is change, or add. (Also, replace doesn't work for v6 either). -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
open() on sockets (sock_no_open)
There are sockets in /proc/pid/fd/, but they can't be opened because of this function: /* * In theory you can't get an open on this inode, but /proc provides * a back door. Remember to keep it shut otherwise you'll let the * creepy crawlies in. */ static int sock_no_open(struct inode *irrelevant, struct file *dontcare) How would I make it possible to open existing sockets? It's possible to duplicate access to the same socket using fork(), but I just seem to be creating a mess when I try to make open() work because it breaks after calling socket_close... is there a way to do this so it works properly? -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On 23/06/07 15:47, C. Scott Ananian wrote: Advertisements it received. I considered storing the *complete* Router Advertisement messages received and pushing them unparsed to userland, just to get around the bogus DNS in the kernel politics (hint: it's not a resolver in the kernel, it's just nameserver addresses being stored). Does anyone really suggest that this would be a better solution? Yes, but I don't think it should be completely unparsed - it should be possible to retrieve the data for a specific attribute type with expiration information and with notification of changes. The kernel has to read RAs anyway, why shouldn't it store them in a way that userspace can access it on demand? A /proc file which is in resolv.conf format is definitely *wrong*, and while I'd argue for DNS being special enough to export its attributes is it really too much to have the kernel provide everything from the last valid message in a partially parsed format? Applications would then parse the data section for RA attributes they understand. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On 23/06/07 02:04, David Stevens wrote: Why not make the application that writes resolv.conf also listen on a raw ICMPv6 socket? I don't believe you'd need any kernel changes, then, and it seems pretty simple and straightforward. Because then it requires yet another network daemon, RA in the kernel means there's no need for one to manage adding auto-configured IP addresses... what's wrong with doing the same for DNS? I don't think it should be in resolv.conf format though. Can't you make a change to glibc too to have it use it properly? Something like hosts: files rdnss dns or an option that can be added to resolv.conf? -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On 23/06/07 05:30, David Stevens wrote: [EMAIL PROTECTED] wrote on 06/22/2007 06:17:46 PM: Is there a reason why you're CC:ing the Sender? Doesn't that end up in the mailbox(es) of the netdev admin(s)? On 23/06/07 02:04, David Stevens wrote: Why not make the application that writes resolv.conf also listen on a raw ICMPv6 socket? I don't believe you'd need any kernel changes, then, and it seems pretty simple and straightforward. Because then it requires yet another network daemon, RA in the kernel means there's no need for one to manage adding auto-configured IP addresses... what's wrong with doing the same for DNS? It's not yet another one, since you have to run something to get it in resolv.conf, anyway. That seems much better to me Well, it'd be the library including it - so there'd be no daemon application involved. than having the kernel track data that can only be used at the application layer. The app itself looks like it'd be really simple. Keeping application data in the kernel does start to get silly though, e.g. everything in dhcp-options(5)... but DNS is used almost everywhere. This could be a configuration option so that anyone who doesn't want it can disable it completely. Auto-configured addresses are used by the kernel. It has to have those addresses. But the kernel doesn't do DNS look-ups, or write resolv.conf; that's the difference, for me. Using DHCPv6 as an example, auto-configuration does not have to be in the kernel at all either. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[IPV6]: Fix routing round-robin locking. breaks manual default route (bug 8349)
= -1 [ 779.705000] rt6_select() = b1b63060 [ 779.713000] rt6_select(fn-leaf=b1b63060, oif=0) [ 779.713000] find_match rt-rt6i_gateway = 80fe ff183002 c225b0fe [ 779.713000] find_match m = 10, *mpri = -1 [ 779.713000] rt6_select() = b1b63060 [ 779.714000] rt6_select(fn-leaf=b1b63ae0, oif=2) [ 779.714000] find_match rt-rt6i_gateway = [ 779.714000] find_match m = 9, *mpri = -1 [ 779.714000] rt6_select() = b1b63ae0 -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: default y idiocy
On 12/05/07 19:23, Jens Axboe wrote: Hi, This has bothered me for a long time, and it just seems to be getting worse. Can people please STOP defaulting non-essential stuff to 'y'? Grrr. Is there a reason why various 10/100/1000Mbit network cards are 'y' too? There's even a default SCSI 'm' that seems to be completely hidden from the menu too (CONFIG_SCSI_WAIT_SCAN). It depends on SCSI but I can't disable SCSI... -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Accessing certain web sites broken from 2.6.19+
On Fri, May 11, 2007 06:16, Andrew Hall wrote: -Original Message- From: Robert Iakobashvili [mailto:[EMAIL PROTECTED] Sent: Friday, 11 May 2007 2:38 PM To: Andrew Hall Cc: netdev@vger.kernel.org Subject: Re: Accessing certain web sites broken from 2.6.19+ On 5/11/07, Andrew Hall [EMAIL PROTECTED] wrote: When accessing certain web sites when using any kernel above 2.6.19, TCP seems to break. Connection to the site is established but never completes. One particular site is www.dcita.gov.au. Is there a known issue pertaining to this? Using any kernel below 2.6.19 (for example: 2.6.12 or 2.6.15) works fine. Including 2.6.21? Which browser/s have you tried? -- Sincerely, Robert Iakobashvili, coroberti %x40 gmail %x2e com ... http://curl-loader.sourceforge.net A web testing and traffic generation tool. I have not yet tried 2.6.21.. only tried to 2.6.20.9. The issue isn't browser dependent ,as a wget directly from the OS will also fail during the connection. Interestingly requests made from hosts behind the 2.6.20 gateway that make the same request work fine, it seems it's only requests made from the localhost itself. Use tcptraceroute with and without -E to check this isn't a problem with ECN. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netconsole system freeze when cable unplugged
On 10/03/07 13:38, Andi Kleen wrote: Simon Arlott [EMAIL PROTECTED] writes: On 09/03/07 20:42, Francois Romieu wrote: Simon Arlott [EMAIL PROTECTED] : When I unplug the cable the system just stops responding to anything, at all. No message is printed to the console when the cable is plugged back in. rtl8139_interrupt (spin_lock(tp-lock)) - rtl8139_weird_interrupt - rtl_check_media - mii_check_media (printk(KERN_INFO %s: link down\n, ...)) [netpoll stuff here] - rtl8139_poll_controller - rtl8139_interrupt *deadlock* See below for my random stuff of the day. Feel free to open a PR at bugzilla.kernel.org if the issue does not go away. The patch doesn't fix it, nothing changes. I'm not sure how this can be debugged if printk won't work... earlyprintk can be called directly (early_printk()) and should work. It won't log over the network of course. It also won't log over the serial console either :( (but that's probably a good thing, it's slow enough to boot with tons of messages to the display because of netconsole and nfs). rtl8139_interrupt - spin_lock(tp-lock) - rtl8139_weird_interrupt - rtl_check_media - mii_check_media - printk(KERN_INFO %s: link down\n, ...) - wite_msg - local_irq_save - netpoll_send_udp - netpoll_send_skb - local_irq_save - dev-hard_start_xmit(..., ...) rtl8139_start_xmit - spin_lock_irqsave *deadlock* -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
netconsole system freeze when cable unplugged
established hash table entries: 8192 (order: 6, 294912 bytes) [ 488.204285] TCP bind hash table entries: 8192 (order: 6, 262144 bytes) [ 488.223278] TCP: Hash tables configured (established 8192 bind 8192) [ 488.229974] TCP reno registered [ 488.285511] Limiting direct PCI/PCI transfers. [ 488.334179] Real Time Clock Driver v1.12ac [ 488.338328] Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds). [ 488.347357] Hangcheck: Using get_cycles(). [ 488.351515] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled [ 488.360916] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 488.367954] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A [ 488.381717] 8139too Fast Ethernet driver 0.9.28 [ 488.389601] eth0: RealTek RTL8139 at 0x2400, 00:02:44:47:d3:ee, IRQ 19 [ 488.396487] netconsole: device eth0 not up yet, forcing it [ 488.402923] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 488.423119] netconsole: carrier detect appears untrustworthy, waiting 100 ms [ 489.684118] netconsole: network logging started [ 489.688832] TCP cubic registered [ 489.694506] NET: Registered protocol family 10 [ 489.711251] Starting balanced_irq [ 489.715459] Using IPI Shortcut mode [ 491.242277] Sending DHCP requests ., OK [ 491.292256] IP-Config: Got DHCP answer from 192.168.7.4, my address is 192.168.7.200 [ 491.302672] IP-Config: Complete: [ 491.305876] device=eth0, addr=192.168.7.200, mask=255.255.255.0, gw=192.168.7.4, [ 491.314553] host=Compaq_PW5000, domain=lan, nis-domain=(none), [ 491.321130] bootserver=192.168.7.4, rootserver=192.168.7.8, rootpath=/ [ 491.331337] Looking up port of RPC 13/2 on 192.168.7.8 [ 491.344971] Looking up port of RPC 15/1 on 192.168.7.8 [ 491.444880] VFS: Mounted root (nfs filesystem) readonly. [ 491.453750] Freeing unused kernel memory: 184k freed [ 491.459420] Write protecting the kernel read-only data: 346k [ 565.518226] eth0: link down -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netconsole system freeze when cable unplugged
On 09/03/07 20:42, Francois Romieu wrote:
Simon Arlott [EMAIL PROTECTED] :
When I unplug the cable the system just stops responding to anything,
at all. No message is printed to the console when the cable is plugged
back in.
rtl8139_interrupt (spin_lock(tp-lock))
- rtl8139_weird_interrupt
- rtl_check_media
- mii_check_media (printk(KERN_INFO %s: link down\n, ...))
[netpoll stuff here]
- rtl8139_poll_controller
- rtl8139_interrupt
*deadlock*
See below for my random stuff of the day. Feel free to open a PR at
bugzilla.kernel.org if the issue does not go away.
The patch doesn't fix it, nothing changes. I'm not sure how this can
be debugged if printk won't work...
8-
8139too: netconsole breakage when link changes
rtl8139_interrupt is not supposed to be reentrant but its link
management part can emit printk.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 99304b2..64467ad 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -2215,9 +2215,16 @@ static irqreturn_t rtl8139_interrupt (int irq, void
*dev_instance)
*/
static void rtl8139_poll_controller(struct net_device *dev)
{
- disable_irq(dev-irq);
+ struct rtl8139_private *tp = netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ rc = spin_trylock_irqsave(tp-lock, flags);
+ if (!rc)
+ return;
+ spin_unlock(tp-lock);
rtl8139_interrupt(dev-irq, dev);
- enable_irq(dev-irq);
+ local_irq_restore(flags);
}
#endif
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Simon Arlott
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
