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
1000mbit.
Signed-off-by: Simon Arlott
---
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
; > 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 cu
__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
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
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.
> 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
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!
>> >[
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, mediu
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:
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
>>
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])
>&g
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)
>> Soc
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
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.4
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:
>>>>&g
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
5.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
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
gt;
> 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 Arl
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 n
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
d:maturity\n", zconf_curname(),
zconf_lineno());
+};
+
/* prompt statement */
prompt_stmt_opt:
@@ -519,6 +535,7 @@ const char *zconf_tokenname(int token)
case T_IF: return "if";
case T_ENDIF: return "endif";
case T_DEPENDS:
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
&
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
>>&
ing?
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
A 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
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
>>
>>
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
s 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
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
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
13000] 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
;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
ied 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 f
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
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(&am
y.
[ 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]
38 matches
Mail list logo
