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
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" (thi
> > 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 curr
__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
.
[ 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
, 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
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
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
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
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
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
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
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
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
- 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
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
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
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
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
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
|
+ 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
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
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
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
) 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
- 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
.
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
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
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
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
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
[ 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
' 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
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
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
[ 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
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
37 matches
Mail list logo
