Re: linkwatch bustage in git-net
On Wed, 9 May 2007 15:45:58 +1000 Herbert Xu [EMAIL PROTECTED] wrote:
On Wed, May 09, 2007 at 03:31:55PM +1000, Herbert Xu wrote:
Hmm, I don't see it here (probably because we use different NICs).
But does this help?
Thinking about it again I don't think it will help you because if your
carrier started out as off then it would've been considered an urgent
event anyway.
So what NIC are you using? And where abouts in the boot process is it
hanging? For exmaple, is it hanging when obtaining a DHCP address?
In any case, this patch can't hurt. So here's one with a changelog:
[NET] link_watch: Eliminate potential delay on wrap-around
hm, that fixed it. Do we know why? ;)
btw, looking at the code:
clear_bit(LW_RUNNING, linkwatch_flags);
spin_lock_irq(lweventlist_lock);
next = lweventlist;
lweventlist = NULL;
spin_unlock_irq(lweventlist_lock);
while (next) {
struct net_device *dev = next;
next = dev-link_watch_next;
lweventlist_lock protects lweventlist and every netdev's -link_watch_next.
But this code is walking that singly-linked list outside the lock and
after clearing LW_RUNNING. What stops this singly-linked list from getting
altered by another thread of control while this code is traversing it?
-
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: linkwatch bustage in git-net
From: Andrew Morton [EMAIL PROTECTED] Date: Tue, 8 May 2007 23:11:43 -0700 On Wed, 9 May 2007 15:45:58 +1000 Herbert Xu [EMAIL PROTECTED] wrote: On Wed, May 09, 2007 at 03:31:55PM +1000, Herbert Xu wrote: Hmm, I don't see it here (probably because we use different NICs). But does this help? Thinking about it again I don't think it will help you because if your carrier started out as off then it would've been considered an urgent event anyway. So what NIC are you using? And where abouts in the boot process is it hanging? For exmaple, is it hanging when obtaining a DHCP address? In any case, this patch can't hurt. So here's one with a changelog: [NET] link_watch: Eliminate potential delay on wrap-around hm, that fixed it. Do we know why? ;) I wonder if, because of how we initialize jiffies on bootup to find wraparound bugs, urgent_event is always true. If it is always true, linkwatch_nextevent will never get updated. Herbert's patch indirectly corrects that. In the mean time I'll stick Herbert's patch into net-2.6 - 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: 2.6.20.7 TCP cubic (and bic) initial slow start way too slow?
Hi Sangtae, On Tue, 8 May 2007, SANGTAE HA wrote: Hi Bill, At this time, BIC and CUBIC use a less aggressive slow start than other protocols. Because we observed slow start is somewhat aggressive and introduced a lot of packet losses. This may be changed to standard slow start in later version of BIC and CUBIC, but, at this time, we still using a modified slow start. slow start is somewhat of a misnomer. However, I'd argue in favor of using the standard slow start for BIC and CUBIC as the default. Is the rationale for using a less agressive slow start to be gentler to certain receivers, which possibly can't handle a rapidly increasing initial burst of packets (and the resultant necessary allocation of system resources)? Or is it related to encountering actual network congestion during the initial slow start period, and how well that is responded to? So, as you observed, this modified slow start behavior may slow for 10G testing. You can alleviate this for your 10G testing by changing BIC and CUBIC to use a standard slow start by loading these modules with initial_ssthresh=0. I saw the initial_ssthresh parameter, but didn't know what it did or even what its units were. I saw the default value was 100 and tried increasing it, but I didn't think to try setting it to 0. [EMAIL PROTECTED] ~]# grep -r initial_ssthresh /usr/src/kernels/linux-2.6.20.7/Documentation/ [EMAIL PROTECTED] ~]# It would be good to have some documentation for these bic and cubic parameters similar to the documentation in ip-sysctl.txt for the /proc/sys/net/ipv[46]/* variables (I know, I know, I should just use the source). Is it expected that the cubic slow start is that much less agressive than the bic slow start (from 10 secs to max rate for bic in my test to 25 secs to max rate for cubic). This could be considered a performance regression since the default TCP was changed from bic to cubic. In any event, I'm now happy as setting initial_ssthresh to 0 works well for me. [EMAIL PROTECTED] ~]# netstat -s | grep -i retrans 0 segments retransmited [EMAIL PROTECTED] ~]# cat /proc/sys/net/ipv4/tcp_congestion_control cubic [EMAIL PROTECTED] ~]# cat /sys/module/tcp_cubic/parameters/initial_ssthresh 0 [EMAIL PROTECTED] ~]# nuttcp -T10 -i1 -w60m 192.168.89.15 69.9829 MB / 1.00 sec = 584.2065 Mbps 843.1467 MB / 1.00 sec = 7072.9052 Mbps 844.3655 MB / 1.00 sec = 7082.6544 Mbps 842.2671 MB / 1.00 sec = 7065.7169 Mbps 839.9204 MB / 1.00 sec = 7045.8335 Mbps 840.1780 MB / 1.00 sec = 7048.3114 Mbps 834.1475 MB / 1.00 sec = 6997.4270 Mbps 835.5972 MB / 1.00 sec = 7009.3148 Mbps 835.8152 MB / 1.00 sec = 7011.7537 Mbps 830.9333 MB / 1.00 sec = 6969.9281 Mbps 7617.1875 MB / 10.01 sec = 6386.2622 Mbps 90 %TX 46 %RX [EMAIL PROTECTED] ~]# netstat -s | grep -i retrans 0 segments retransmited -Thanks a lot! -Bill Regards, Sangtae On 5/6/07, Bill Fink [EMAIL PROTECTED] wrote: The initial TCP slow start on 2.6.20.7 cubic (and to a lesser extent bic) seems to be way too slow. With an ~80 ms RTT, this is what cubic delivers (thirty second test with one second interval reporting and specifying a socket buffer size of 60 MB): [EMAIL PROTECTED] ~]# netstat -s | grep -i retrans 0 segments retransmited [EMAIL PROTECTED] ~]# cat /proc/sys/net/ipv4/tcp_congestion_control cubic [EMAIL PROTECTED] ~]# nuttcp -T30 -i1 -w60m 192.168.89.15 6.8188 MB / 1.00 sec = 57.0365 Mbps 16.2097 MB / 1.00 sec = 135.9824 Mbps 25.4553 MB / 1.00 sec = 213.5420 Mbps 35.5127 MB / 1.00 sec = 297.9119 Mbps 43.0066 MB / 1.00 sec = 360.7770 Mbps 50.3210 MB / 1.00 sec = 422.1370 Mbps 59.0796 MB / 1.00 sec = 495.6124 Mbps 69.1284 MB / 1.00 sec = 579.9098 Mbps 76.6479 MB / 1.00 sec = 642.9130 Mbps 90.6189 MB / 1.00 sec = 760.2835 Mbps 109.4348 MB / 1.00 sec = 918.0361 Mbps 128.3105 MB / 1.00 sec = 1076.3813 Mbps 150.4932 MB / 1.00 sec = 1262.4686 Mbps 175.9229 MB / 1.00 sec = 1475.7965 Mbps 205.9412 MB / 1.00 sec = 1727.6150 Mbps 240.8130 MB / 1.00 sec = 2020.1504 Mbps 282.1790 MB / 1.00 sec = 2367.1644 Mbps 318.1841 MB / 1.00 sec = 2669.1349 Mbps 372.6814 MB / 1.00 sec = 3126.1687 Mbps 440.8411 MB / 1.00 sec = 3698.5200 Mbps 524.8633 MB / 1.00 sec = 4403.0220 Mbps 614.3542 MB / 1.00 sec = 5153.7367 Mbps 718.9917 MB / 1.00 sec = 6031.5386 Mbps 829.0474 MB / 1.00 sec = 6954.6438 Mbps 867.3289 MB / 1.00 sec = 7275.9510 Mbps 865.7759 MB / 1.00 sec = 7262.9813 Mbps 864.4795 MB / 1.00 sec = 7251.7071 Mbps 864.5425 MB / 1.00 sec = 7252.8519 Mbps 867.3372 MB / 1.00 sec = 7246.9232 Mbps 10773.6875 MB / 30.00 sec = 3012.3936 Mbps 38 %TX 25 %RX [EMAIL PROTECTED] ~]# netstat -s | grep -i
Re: [PATCH] sched: Optimize return value of qdisc_restart
From: Krishna Kumar2 [EMAIL PROTECTED] Date: Wed, 9 May 2007 10:05:57 +0530 This change will not change existing behavior in case there are packets in the queue, it will return -1 each time as does the original code. But when there are no packets, the original qdisc_restart returns -1 and the caller will unnecessarily call qdisc_restart which branches to the bottom and returns 0 (qlen). This call can be avoided if we had returned 0 in the previous iteration. Branching to the bottom cannot be done since it breaks the packets present case, as it will return a positive number and the caller will assume that the queue is throttled. Ok, thanks for the explanation. But this only makes sense for the second hunk you changed. The first hunk is a bug case, an improper looping device decapsulation condition, and we do want to always return -1 in that case in order to break out of the loop. Your change will make the kernel essentially hang instead when this bug check is triggered. - 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: [1/1 take 2] Unified socket storage. (with small bench).
From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Tue, 8 May 2007 21:43:32 +0400 This is second patch which implements unified cache of sockets for network instead of old hash tables. It stores all types of sockets (although I only implemented af_inet, unix, netlink and raw ones for now) in single object structure called multidimensional trie (which is similar to judy array in some way). Thanks for doing this work it is very interesting. :) So, this is dynamic structure which can host any kind of network sockets (actually any structure pointer which can be addressed with 160 bits). Structure can be extended to support ipv6 (needs to increase key length) with essentially any number of elements in it. Code is in development stage, but I would like to rise a discussion about needs to continue this development before next steps. One thing that will need to be adjust for current tree is the UDP hashing mechanism. But as far as I can tell your code should be able to handle the new scheme (we now hash UDP by saddr+port when possible, and this reminds me that IPV6 is broken and needs some repairs). What exactly does the 'stages' arg mean? Is this a method to handle partially bound sockets? - 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: Unexcepted latency (order of 100-200 ms) with TCP (packet receive)
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Mon, 7 May 2007 14:45:53 +0300 (EEST)
I found out this shows up when 900fd17dd01d2c99dfd1ec0b53a860894a2673ee is
included, kernels before that seem to work fine. The problem description
is in this same thread. I'm not going to repeat it here as it is valid
except for the fact that my original claim that it happens with another
hardware is false, please see it in here:
http://marc.info/?l=linux-netdevm=117758295411277w=2
Should these delays I see be considered as evindence of mmio not working
with this card/model or could there be something else wrong somewhere?
...I can just disable it using global_use_mmio parameter, which removes
the problem in 2.6.20.7 (tested) but just in case somebody has more clue
than I do about this, I'm willing to do more testing...
One thing that MMIO changes a lot is timing.
The port I/O instructions on x86 have fixed timings so take the same
amount of time to execute regardless of the underlying bus
capabilities.
This could have been masking some issue in the driver or the hardware.
Port I/O also does not have any write posting issues like MMIO does.
In my opinion it can only cause trouble to start using MMIO on such
old chips when we've been using port I/O to access them for 5+ years.
:-)
Wait, it's timing, I see the bug. There was a similar problem like
this in the Linux floppy driver some 6 years ago.
Look at issue_and_wait(), how it polls:
iowrite16(cmd, ioaddr + EL3_CMD);
for (i = 0; i 2000; i++) {
if (!(ioread16(ioaddr + EL3_STATUS) CmdInProgress))
return;
}
That takes longer to run with port I/O than MMIO. So I bet it
breaks out of the loop faster with MMIO and thus can trigger
this thing:
/* OK, that didn't work. Do it the slow way. One second */
for (i = 0; i 10; i++) {
if (!(ioread16(ioaddr + EL3_STATUS) CmdInProgress)) {
if (vortex_debug 1)
printk(KERN_INFO %s: command 0x%04x took %d
usecs\n,
dev-name, cmd, i * 10);
return;
}
udelay(10);
}
and that's where your delays are coming from.
I would suggest adding some kind of (very small) fixed delay to the
first loop.
The rest of the driver should be audited for this kind of problem.
-
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: linkwatch bustage in git-net
On Tue, May 08, 2007 at 11:11:43PM -0700, Andrew Morton wrote:
[NET] link_watch: Eliminate potential delay on wrap-around
hm, that fixed it. Do we know why? ;)
Yep :)
btw, looking at the code:
clear_bit(LW_RUNNING, linkwatch_flags);
spin_lock_irq(lweventlist_lock);
next = lweventlist;
lweventlist = NULL;
spin_unlock_irq(lweventlist_lock);
while (next) {
struct net_device *dev = next;
next = dev-link_watch_next;
lweventlist_lock protects lweventlist and every netdev's -link_watch_next.
But this code is walking that singly-linked list outside the lock and
after clearing LW_RUNNING. What stops this singly-linked list from getting
altered by another thread of control while this code is traversing it?
It's protected by the __LINK_STATE_LINKWATCH_PENDING bit.
The real problem here is a combination of factors. First of all e100
does a netif_carrier_off in its open routine *before* the first call
to dev_activate. This when combined with the wrap-around bug causes
an infinitely delayed event for your NIC to be installed.
When the carrier comes up it notices that we already have an event
queued for that NIC so it just drops it even though it's urgent.
The previous bug fix limits this delay to one second but it is still
sub-optimal.
So here is the additional fix.
[NET] link_watch: Always schedule urgent events
Urgent events may be delayed if we already have a non-urgent event
queued for that device. This patch changes this by making sure that
an urgent event is always looked at immediately.
I've replaced the LW_RUNNING flag by LW_URGENT since whether work
is scheduled is already kept track by the work queue system.
The only complication is that we have to provide some exclusion for
the setting linkwatch_nextevent which is available in the actual
work function.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/core/link_watch.c b/net/core/link_watch.c
index 4674ae5..a5e372b 100644
--- a/net/core/link_watch.c
+++ b/net/core/link_watch.c
@@ -26,7 +26,7 @@
enum lw_bits {
- LW_RUNNING = 0,
+ LW_URGENT = 0,
};
static unsigned long linkwatch_flags;
@@ -95,18 +95,41 @@ static void linkwatch_add_event(struct net_device *dev)
}
-static void linkwatch_schedule_work(unsigned long delay)
+static void linkwatch_schedule_work(int urgent)
{
- if (test_and_set_bit(LW_RUNNING, linkwatch_flags))
+ unsigned long delay = linkwatch_nextevent - jiffies;
+
+ if (test_bit(LW_URGENT, linkwatch_flags))
return;
- /* If we wrap around we'll delay it by at most HZ. */
- if (delay HZ) {
- linkwatch_nextevent = jiffies;
+ /* Minimise down-time: drop delay for up event. */
+ if (urgent) {
+ if (test_and_set_bit(LW_URGENT, linkwatch_flags))
+ return;
delay = 0;
}
- schedule_delayed_work(linkwatch_work, delay);
+ /* If we wrap around we'll delay it by at most HZ. */
+ if (delay HZ)
+ delay = 0;
+
+ /*
+* This is true if we've scheduled it immeditately or if we don't
+* need an immediate execution and it's already pending.
+*/
+ if (schedule_delayed_work(linkwatch_work, delay) == !delay)
+ return;
+
+ /* Don't bother if there is nothing urgent. */
+ if (!test_bit(LW_URGENT, linkwatch_flags))
+ return;
+
+ /* It's already running which is good enough. */
+ if (!cancel_delayed_work(linkwatch_work))
+ return;
+
+ /* Otherwise we reschedule it again for immediate exection. */
+ schedule_delayed_work(linkwatch_work, 0);
}
@@ -123,7 +146,11 @@ static void __linkwatch_run_queue(int urgent_only)
*/
if (!urgent_only)
linkwatch_nextevent = jiffies + HZ;
- clear_bit(LW_RUNNING, linkwatch_flags);
+ /* Limit wrap-around effect on delay. */
+ else if (time_after(linkwatch_nextevent, jiffies + HZ))
+ linkwatch_nextevent = jiffies;
+
+ clear_bit(LW_URGENT, linkwatch_flags);
spin_lock_irq(lweventlist_lock);
next = lweventlist;
@@ -166,7 +193,7 @@ static void __linkwatch_run_queue(int urgent_only)
}
if (lweventlist)
- linkwatch_schedule_work(linkwatch_nextevent - jiffies);
+ linkwatch_schedule_work(0);
}
@@ -187,21 +214,16 @@ static void linkwatch_event(struct work_struct *dummy)
void linkwatch_fire_event(struct net_device *dev)
{
- if (!test_and_set_bit(__LINK_STATE_LINKWATCH_PENDING, dev-state)) {
- unsigned long delay;
+ int urgent = linkwatch_urgent_event(dev);
Re: linkwatch bustage in git-net
From: Herbert Xu [EMAIL PROTECTED] Date: Wed, 9 May 2007 17:16:15 +1000 The real problem here is a combination of factors. First of all e100 does a netif_carrier_off in its open routine *before* the first call to dev_activate. This when combined with the wrap-around bug causes an infinitely delayed event for your NIC to be installed. I noticed that behavior of e100 too. [NET] link_watch: Always schedule urgent events Urgent events may be delayed if we already have a non-urgent event queued for that device. This patch changes this by making sure that an urgent event is always looked at immediately. I've replaced the LW_RUNNING flag by LW_URGENT since whether work is scheduled is already kept track by the work queue system. The only complication is that we have to provide some exclusion for the setting linkwatch_nextevent which is available in the actual work function. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Thanks for working this out, applied and pushed to net-2.6.git - 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] sched: Optimize return value of qdisc_restart
David Miller [EMAIL PROTECTED] wrote on 05/09/2007 12:06:30 PM: But this only makes sense for the second hunk you changed. I think it should work fine for both. The first hunk is a bug case, an improper looping device decapsulation condition, and we do want to always return -1 in that case in order to break out of the loop. I guess you meant we do *not* want to always return -1 ? Your change will make the kernel essentially hang instead when this bug check is triggered. By returning -1, we end up freeing all the skbs one by one, or until the condition : transient error caused by hard_start_xmit recursing is over. Essentially, that behavior is also not changed in my patch (only run time change is to return 0 if there are no more skbs). Thanks, - KK - 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] spidernet: remove unnecessary accesses to phy
This patch removes unnecessary accesses to phy registers.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
---
Index: linux-powerpc-git/drivers/net/spider_net.c
diff -u linux-powerpc-git/drivers/net/spider_net.c:1.1.1.9
linux-powerpc-git/drivers/net/spider_net.c:1.14
--- linux-powerpc-git/drivers/net/spider_net.c:1.1.1.9 Tue May 8 09:41:28 2007
+++ linux-powerpc-git/drivers/net/spider_net.c Tue May 8 10:16:59 2007
@@ -175,12 +175,10 @@
{
struct mii_phy *phy = card-phy;
u32 advertise = 0;
- u16 bmcr, bmsr, stat1000, estat;
+ u16 bmsr, estat;
- bmcr = spider_net_read_phy(card-netdev, phy-mii_id, MII_BMCR);
- bmsr = spider_net_read_phy(card-netdev, phy-mii_id, MII_BMSR);
- stat1000 = spider_net_read_phy(card-netdev, phy-mii_id, MII_STAT1000);
- estat= spider_net_read_phy(card-netdev, phy-mii_id, MII_ESTATUS);
+ bmsr = spider_net_read_phy(card-netdev, phy-mii_id, MII_BMSR);
+ estat = spider_net_read_phy(card-netdev, phy-mii_id, MII_ESTATUS);
if (bmsr BMSR_10HALF)
advertise |= ADVERTISED_10baseT_Half;
-
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
unregister_netdevice of tap interface blocks for up to 30 secs when ipv6 module loaded
If the ipv6 module is loaded, then destroying a tap interface that has recently been disabled will cause close to block (in unregister_netdevice) until precisely 30 seconds have elapsed since the interface was disabled. This behavior does not occur if the ipv6 module is not loaded, nor if the tap interface is still enabled when calling close, nor if the tap interface has never been enabled. If close is called less than 20 seconds after the interface has been disabled (so that it blocks for 10 seconds), then the following message is output: Message from [EMAIL PROTECTED] at Tue May 8 19:01:04 2007 ... bs18 kernel: unregister_netdevice: waiting for tap0 to become free. Usage count = 3 The attached Python script reliably reproduces this problem. The timestamps in the output show the 30 second delay between running 'ip link set tap0 down' and the subsequent call to close returning. I have tested on two machines, both running Fedora Core 6, one with kernel 2.6.19 and one with kernel 2.6.20, and both machines exhibit the same symptoms. $ cat /proc/version Linux version 2.6.19-1.2895.fc6 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Wed Jan 10 19:28:18 EST 2007 Linux version 2.6.20-1.2933.fc6 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Mon Mar 19 11:38:26 EDT 2007 I have also found the same symptoms to occur on a qemu virtual machine (running a custom 2.6.20 kernel) with minimal user-space code running (just syslogd, klogd, udevd, login and bash), which suggests that this isn't related to any badly-behaving user-space code. Please cc any responses to me, as I'm not on the mailing list. Thanks. James.#!/usr/bin/python import os, time, struct, fcntl # The following are from linux/if_tun.h TUNSETIFF = 0x400454ca # ioctl to configure a TUN/TAP interface IFF_TAP = 0x0002 # Ethernet-level tunnel interface IFF_NO_PI = 0x1000 # Protocol information header for tap interfaces intf = 'tap0' # Create a tap interface. tapFd = os.open( '/dev/net/tun', os.O_RDWR ) ioctlData = struct.pack( '16s H 14x', intf, IFF_TAP | IFF_NO_PI ) fcntl.ioctl( tapFd, TUNSETIFF, ioctlData ) # Enable then disable the tap interface. os.system( 'ip link set %s up' % intf ) print 'Enabled tap interface at', time.ctime( time.time() ) time.sleep( 1 ) # A delay here seems to be necessary to trigger the bug. os.system( 'ip link set %s down' % intf ) print 'Disabled tap interface at', time.ctime( time.time() ) time.sleep( 17 ) # A delay here is not necessary, but illustrates that the 30 second # interval starts when the interface is disabled, not when close is # called. # Destroy the tap interface. print 'About to close tap FD at', time.ctime( time.time() ) os.close( tapFd ) print 'Closed tap FD at', time.ctime( time.time() )
[IPV6] ROUTE: Assign rt6i_idev for ip6_{prohibit,blk_hole}_entry.
We need to assign rt6i_idev for ip6_{prohibit,blk_hole}_entry as well
as we are doing for ip6_null_entry.
2.6.20-stable also needs this.
Closes: Bug#8450
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 452a82c..d1a9827 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4060,6 +4060,10 @@ int __init addrconf_init(void)
return err;
ip6_null_entry.rt6i_idev = in6_dev_get(loopback_dev);
+#ifdef CONFIG_IPV6_MULTIPLE_TABLES
+ ip6_prohibit_entry.rt6i_idev = in6_dev_get(loopback_dev);
+ ip6_blk_hole_entry.rt6i_idev = in6_dev_get(loopback_dev);
+#endif
register_netdevice_notifier(ipv6_dev_notf);
--
YOSHIFUJI Hideaki @ USAGI Project [EMAIL PROTECTED]
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
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] sched: Optimize return value of qdisc_restart
From: Krishna Kumar2 [EMAIL PROTECTED] Date: Wed, 9 May 2007 12:53:05 +0530 David Miller [EMAIL PROTECTED] wrote on 05/09/2007 12:06:30 PM: Your change will make the kernel essentially hang instead when this bug check is triggered. By returning -1, we end up freeing all the skbs one by one, or until the condition : transient error caused by hard_start_xmit recursing is over. Essentially, that behavior is also not changed in my patch (only run time change is to return 0 if there are no more skbs). Something this evening is obviously making it impossible for my brain to understand this function and your patch, so I'm going to sleep on it and try again tomorrow :-) - 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: [IPV6] ROUTE: Assign rt6i_idev for ip6_{prohibit,blk_hole}_entry.
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED]
Date: Wed, 09 May 2007 17:05:50 +0900 (JST)
We need to assign rt6i_idev for ip6_{prohibit,blk_hole}_entry as well
as we are doing for ip6_null_entry.
2.6.20-stable also needs this.
Closes: Bug#8450
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Applied, and I'll push to -stable, thanks.
-
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
American Veterinarian Data - 100k records
This week's special: -- - New Database : American Veterinarians Offices - -- Fields: Veterinarian's ame, Postal Address, Phone, Fax, Email and Website Date Created: Apr 7, 2007 Format: MS Excel License: Unlimited Use Breakdown: 78,986 Total Records 1,438 Emails 1,050 Faxes Special price until May 4 - $149 Inquiries, please email [EMAIL PROTECTED] To stop receiving emails from us please email with off in the subject. - 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: [IPV6] ROUTE: Assign rt6i_idev for ip6_{prohibit,blk_hole}_entry.
In article [EMAIL PROTECTED] (at Wed, 09 May 2007 01:13:33 -0700 (PDT)),
David Miller [EMAIL PROTECTED] says:
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED]
Date: Wed, 09 May 2007 17:05:50 +0900 (JST)
We need to assign rt6i_idev for ip6_{prohibit,blk_hole}_entry as well
as we are doing for ip6_null_entry.
2.6.20-stable also needs this.
Closes: Bug#8450
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Applied, and I'll push to -stable, thanks.
Wait for a moment, please.
I thought it should fix the issue, but
I must say, the fix does not seem sufficient...
I'm now analysing further.
--yoshfuji
-
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
bus id in PHY Abstraction Layer
Hi, I made a quick shot to port the at91 network driver to the phy abstraction layer. While doing so I stumbled upon the (struct mii_bus)-id field. Currently the network driver registering the bus has to set this field. au1000_eth.c for example uses 0 or 1. mii-fec.c uses the id field of the corresponding platform device, which will start from 0, too. So if a second ethernet driver comes around the id fields will clash. I think the PAL has to assign the id field instead of the network driver. Maybe a id convention like mii_fec.x:yy where x is a running number and yy is the phy address would do it. Any opinions about that? Sascha -- Pengutronix - Linux Solutions for Science and Industry Entwicklungszentrum Nord http://www.pengutronix.de - 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] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Krzysztof Halasa wrote: Lennert Buytenhek [EMAIL PROTECTED] writes: There _is_ an ARM BE version of Debian. It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is. Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround? Please keep in mind that users are unlikely to install an unofficial port which lacks integration with the Debian infrastructure, security support and other services. The arm architecture (LE) is currently the third most popular in Debian, whereas I suspect (?) there are very few BE Debian systems out there. Marcus - 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] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, May 09, 2007 at 10:58:06AM +0200, Marcus Better wrote: There _is_ an ARM BE version of Debian. It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is. Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround? Please keep in mind that users are unlikely to install an unofficial port which lacks integration with the Debian infrastructure, security support and other services. The arm architecture (LE) is currently the third most popular in Debian, whereas I suspect (?) there are very few BE Debian systems out there. Note that all of your arguments also apply to the experimental EABI little-endian ARM port. I.e.: 1. The EABI port is an unofficial port. 2. The EABI port is not integrated with the Debian infrastructure. 3. The EABI port lacks security support. You could also argue that: 4. There is no reason to use EABI -- old-ABI works just as well. 5. The perceived floating point speedups that EABI gives are completely drowned out by the slowness of the rest of the system. 6. A lot of programs assume old-ABI behavior, it is too much work to patch them all. Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? I think you've just summarised why I don't like working on Debian. - 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] vlan: lockdep subclass for ppp _xmit_lock Re: ppp_generic: fix lockdep warning
On Thu, Apr 26, 2007 at 12:49:50PM +0200, Jarek Poplawski wrote:
...
But there is also a second, very similar lockdep report,
probably also false (lockdep cannot see the difference
between locks of two different, I hope, vlan devices),
which needs more work:
a) vlan should use different lockdep lock subclasses or
classes for each device, which would require quite a lot
of static memory reserved, probably only to silence
lockdep,
b) pppoe could change the way of sending packets, so
the locks of ppp_generic were not seen by lockdep
with so many variants; I'm not sure the maintainer of
pppoe likes this idea;
Doing a) should be enough, I guess; doing b) is easier
but, probably, the similar is possible elsewhere, too.
...
Currently I think about some change in lockdep, to track
something like different vlans with less memory, but I'm
not sure it'll work, yet.
After rethinking there is the 3-rd way (as usual):
c) vlan should use different lockdep lock subclasses or
classes for different types of devices, used at the same
time.
This patch is intended for testing, so should be applied
after some confirmation. (It should be safe anyway.)
If this works, the previous lockdep patch on ppp_generic
should be really superfluous.
Yuriy, could you try this patch, please?
This is done on 2.6.21, but could be applied to current -mm
or -git, too. If you prefere some other version, let me know.
Regards,
Jarek P.
---
This patch's aim is to let lockdep see ppp devs as different
from others (default), and it's OK to take: _xmit_lock of vlan
and _xmit_lock of ppp with reverse order provided vlan _xmit_locks
are bound to different devs (ppp and e.g. eth).
===
[ INFO: possible circular locking dependency detected ]
2.6.21-rc6-mm1 #4
---
pppd/14305 is trying to acquire lock:
(vlan_netdev_xmit_lock_key){-...}, at: [8022f90b]
dev_queue_xmit+0x26b/0x300
but task is already holding lock:
(pch-downl#2){-+..}, at: [80388d3c] ppp_push+0x5f/0xa7
which lock already depends on the new lock.
Reported tested by: Yuriy N. Shkandybin [EMAIL PROTECTED]
Cc: Ben Greear [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Michal Ostrowski [EMAIL PROTECTED]
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp 2.6.21-/net/8021q/vlan.c 2.6.21/net/8021q/vlan.c
--- 2.6.21-/net/8021q/vlan.c2007-05-01 12:43:39.0 +0200
+++ 2.6.21/net/8021q/vlan.c 2007-05-07 21:09:30.0 +0200
@@ -535,7 +535,13 @@ static struct net_device *register_vlan_
if (register_netdevice(new_dev))
goto out_free_newdev;
- lockdep_set_class(new_dev-_xmit_lock, vlan_netdev_xmit_lock_key);
+ if (unlikely(real_dev-type == ARPHRD_PPP))
+ /* pppoe uses two different kinds of _xmit_lock for ppp eth */
+ lockdep_set_class_and_subclass(new_dev-_xmit_lock,
+ vlan_netdev_xmit_lock_key, 1);
+ else
+ lockdep_set_class(new_dev-_xmit_lock,
+ vlan_netdev_xmit_lock_key);
new_dev-iflink = real_dev-ifindex;
vlan_transfer_operstate(real_dev, new_dev);
-
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: [1/1 take 2] Unified socket storage. (with small bench).
On Tue, May 08, 2007 at 11:48:28PM -0700, David Miller ([EMAIL PROTECTED]) wrote: From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Tue, 8 May 2007 21:43:32 +0400 This is second patch which implements unified cache of sockets for network instead of old hash tables. It stores all types of sockets (although I only implemented af_inet, unix, netlink and raw ones for now) in single object structure called multidimensional trie (which is similar to judy array in some way). Thanks for doing this work it is very interesting. :) :) it is interesting indeed. So, this is dynamic structure which can host any kind of network sockets (actually any structure pointer which can be addressed with 160 bits). Structure can be extended to support ipv6 (needs to increase key length) with essentially any number of elements in it. Code is in development stage, but I would like to rise a discussion about needs to continue this development before next steps. One thing that will need to be adjust for current tree is the UDP hashing mechanism. But as far as I can tell your code should be able to handle the new scheme (we now hash UDP by saddr+port when possible, and this reminds me that IPV6 is broken and needs some repairs). Yes, udp with multicast can be a problem, but it can be solved exactly the same way I implemented netlink broadcast (simple solution) - multicast sockets are placed into own list/hash table/trie with special bit in key/whatever and accessed when needed. What exactly does the 'stages' arg mean? Is this a method to handle partially bound sockets? It is a fallback to select a listening socket, which has remote addr/port as zero, so when socket it selected from tree, lookup wants to first get established socket with given remote identity and if this fails, it tries to select a wildcard one. -- Evgeniy Polyakov - 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: smp_affinity, MSI-X and 2.6.21.1
Rick Jones [EMAIL PROTECTED] writes: Folks - Is it a bug, or a feature that after changing a device's smp_affinity via echo N /proc/irq/M/smp_affinity that the new mask isn't visible via cat /proc/irq/M/smp_affinity until after actual interrupts are taken? Intel chipsets can only safely update affinity during interrupt processing. You see a side effect of the code implementing this restriction. -Andi - 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: [1/1 take 2] Unified socket storage. (with small bench).
From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Wed, 9 May 2007 13:34:43 +0400 On Tue, May 08, 2007 at 11:48:28PM -0700, David Miller ([EMAIL PROTECTED]) wrote: One thing that will need to be adjust for current tree is the UDP hashing mechanism. But as far as I can tell your code should be able to handle the new scheme (we now hash UDP by saddr+port when possible, and this reminds me that IPV6 is broken and needs some repairs). Yes, udp with multicast can be a problem, but it can be solved exactly the same way I implemented netlink broadcast (simple solution) - multicast sockets are placed into own list/hash table/trie with special bit in key/whatever and accessed when needed. Actually, I am not talking about multicast. :) In 2.6.22 what happens now in UDP is that if a non-wildcard rcv_saddr is specified, we try to hash using the rcv_saddr and the port. But when binding we have to check first if an existing port+wildcard bind exists. See __udp_lib_get_port() in Linus's current tree. What exactly does the 'stages' arg mean? Is this a method to handle partially bound sockets? It is a fallback to select a listening socket, which has remote addr/port as zero, so when socket it selected from tree, lookup wants to first get established socket with given remote identity and if this fails, it tries to select a wildcard one. This kind of logic also has implications for UDP. :-) - 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: smp_affinity, MSI-X and 2.6.21.1
From: Andi Kleen [EMAIL PROTECTED] Date: 09 May 2007 12:35:29 +0200 Rick Jones [EMAIL PROTECTED] writes: Folks - Is it a bug, or a feature that after changing a device's smp_affinity via echo N /proc/irq/M/smp_affinity that the new mask isn't visible via cat /proc/irq/M/smp_affinity until after actual interrupts are taken? Intel chipsets can only safely update affinity during interrupt processing. You see a side effect of the code implementing this restriction. That's true, but we are talking about software state so in some sense it might be better that the affinity-to-be is reported to the user in this case. Delayed register updates are an implementation detail the user does not need to know about here. - 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: [1/1 take 2] Unified socket storage. (with small bench).
On Wed, May 09, 2007 at 02:44:45AM -0700, David Miller ([EMAIL PROTECTED]) wrote: From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Wed, 9 May 2007 13:34:43 +0400 On Tue, May 08, 2007 at 11:48:28PM -0700, David Miller ([EMAIL PROTECTED]) wrote: One thing that will need to be adjust for current tree is the UDP hashing mechanism. But as far as I can tell your code should be able to handle the new scheme (we now hash UDP by saddr+port when possible, and this reminds me that IPV6 is broken and needs some repairs). Yes, udp with multicast can be a problem, but it can be solved exactly the same way I implemented netlink broadcast (simple solution) - multicast sockets are placed into own list/hash table/trie with special bit in key/whatever and accessed when needed. Actually, I am not talking about multicast. :) In 2.6.22 what happens now in UDP is that if a non-wildcard rcv_saddr is specified, we try to hash using the rcv_saddr and the port. But when binding we have to check first if an existing port+wildcard bind exists. See __udp_lib_get_port() in Linus's current tree. I saw that discussion in netdev@, it is a good solution, but it could be moved further. What exactly does the 'stages' arg mean? Is this a method to handle partially bound sockets? It is a fallback to select a listening socket, which has remote addr/port as zero, so when socket it selected from tree, lookup wants to first get established socket with given remote identity and if this fails, it tries to select a wildcard one. This kind of logic also has implications for UDP. :-) That is only because we have very different way of working with udp. In udp hash table we can have multiple sockets bound to different ip addresses, but with the same port, so it will be placed into the same hash chain. With trie each socket will have differnet key, since addresses are different (or bound device number), so it automatically fixes problem with broken hash for udp (which is a bit fixed with extended hashing). User can also specify remote address for given socket (actually netchannels use this in netfilter implementation), in that case only given set of ids (remote/local addr/port) will be used to select a socket, which can be a some kind of simple netfilter... -- Evgeniy Polyakov - 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] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lennert Buytenhek wrote: Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver. Marcus pgpXZAXckxl8V.pgp Description: PGP signature
Re: [1/1 take 2] Unified socket storage. (with small bench).
From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Wed, 9 May 2007 13:57:40 +0400 That is only because we have very different way of working with udp. In udp hash table we can have multiple sockets bound to different ip addresses, but with the same port, so it will be placed into the same hash chain. With trie each socket will have differnet key, since addresses are different (or bound device number), so it automatically fixes problem with broken hash for udp (which is a bit fixed with extended hashing). Yes it is power of trie. So connection rates are interesting, but what about raw lookup performance? Last time this topic came up you went into some cave when you looked at the trie lookup assembly and compared it to hash. :) It does make more memory references than hash by definition, and we need to figure out whether that matters enough or not. - 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] [IPV6]: Do no rely on skb-dst before it is assigned.
Because skb-dst is assigned in ip6_route_input(), it is really
bad to use it in hop-by-hop option handler(s).
This fix is also needed for -stable.
Closes: Bug #8450 (Eric Sesterhenn [EMAIL PROTECTED])
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index fb39604..1e6e67e 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -651,6 +651,14 @@ EXPORT_SYMBOL_GPL(ipv6_invert_rthdr);
Hop-by-hop options.
**/
+/*
+ * Note: we cannot rely on skb-dst before we assign it in ip6_route_input().
+ */
+static inline struct inet6_dev *ipv6_skb_idev(struct sk_buff *skb)
+{
+ return skb-dst ? ip6_dst_idev(skb-dst) : __in6_dev_get(skb-dev);
+}
+
/* Router Alert as of RFC 2711 */
static int ipv6_hop_ra(struct sk_buff **skbp, int optoff)
@@ -677,25 +685,25 @@ static int ipv6_hop_jumbo(struct sk_buff **skbp, int
optoff)
if (skb-nh.raw[optoff+1] != 4 || (optoff3) != 2) {
LIMIT_NETDEBUG(KERN_DEBUG ipv6_hop_jumbo: wrong jumbo opt
length/alignment %d\n,
skb-nh.raw[optoff+1]);
- IP6_INC_STATS_BH(ip6_dst_idev(skb-dst),
+ IP6_INC_STATS_BH(ipv6_skb_idev(skb),
IPSTATS_MIB_INHDRERRORS);
goto drop;
}
pkt_len = ntohl(*(__be32*)(skb-nh.raw+optoff+2));
if (pkt_len = IPV6_MAXPLEN) {
- IP6_INC_STATS_BH(ip6_dst_idev(skb-dst),
IPSTATS_MIB_INHDRERRORS);
+ IP6_INC_STATS_BH(ipv6_skb_idev(skb), IPSTATS_MIB_INHDRERRORS);
icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, optoff+2);
return 0;
}
if (skb-nh.ipv6h-payload_len) {
- IP6_INC_STATS_BH(ip6_dst_idev(skb-dst),
IPSTATS_MIB_INHDRERRORS);
+ IP6_INC_STATS_BH(ipv6_skb_idev(skb), IPSTATS_MIB_INHDRERRORS);
icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, optoff);
return 0;
}
if (pkt_len skb-len - sizeof(struct ipv6hdr)) {
- IP6_INC_STATS_BH(ip6_dst_idev(skb-dst),
IPSTATS_MIB_INTRUNCATEDPKTS);
+ IP6_INC_STATS_BH(ipv6_skb_idev(skb),
IPSTATS_MIB_INTRUNCATEDPKTS);
goto drop;
}
--
YOSHIFUJI Hideaki @ USAGI Project [EMAIL PROTECTED]
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
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] ROUTE: Assign rt6i_idev for ip6_{prohibit,blk_hole}_entry.
I think this is less critical, but is also suitable for -stable release. Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 452a82c..d1a9827 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -4060,6 +4060,10 @@ int __init addrconf_init(void) return err; ip6_null_entry.rt6i_idev = in6_dev_get(loopback_dev); +#ifdef CONFIG_IPV6_MULTIPLE_TABLES + ip6_prohibit_entry.rt6i_idev = in6_dev_get(loopback_dev); + ip6_blk_hole_entry.rt6i_idev = in6_dev_get(loopback_dev); +#endif register_netdevice_notifier(ipv6_dev_notf); -- YOSHIFUJI Hideaki @ USAGI Project [EMAIL PROTECTED] GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - 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] Intel IXP4xx network drivers v.3 - QMGR
On Tue, May 08, 2007 at 06:59:36PM +0200, Krzysztof Halasa wrote: There may be up to 6 Ethernet ports (not sure about hardware status, not yet supported even by Intel) - 7 queues * 128 entries each = ~ 3.5 KB. Add 2 long queues (RX) for HSS and something for TX, and then crypto, and maybe other things. You're unlikely to be using all of those at the same time, though. That's the point. And what do you do if the user does compile all of these features into his kernel and then tries to use them all at the same time? Return -ENOMEM? If he is able to do so, yes - there is nothing we can do. But I suspect a single machine would not have all possible hardware. The problem is, we don't know what would it have, so it must be dynamic. Well, you _would_ like to have a way to make sure that all the capabilities on the board can be used. If you have a future ixp4xx based board with 16 ethernet ports, you don't want 'ifconfig eth7 up' to give you -ENOMEM just because we ran out of SRAM. The way I see it, that means that you do want to scale back your other SRAM allocations if you know that you're going to need a lot of SRAM (say, for ethernet RX/TX queues.) Either you can do this with an ugly hack a la: /* * The FOO board has many ethernet ports, and runs out of * SRAM prematurely if we use the default TX/RX ring sizes. */ #ifdef CONFIG_MACH_IXP483_FOO_BOARD #define IXP4XX_ETH_RXTX_QUEUE_SIZE 32 #else #define IXP4XX_ETH_RXTX_QUEUE_SIZE 256 #endif Or you can put this knowledge in the board support code (cleaner, IMHO.) E.g. let arch/arm/mach-ixp4xx/nslu2.c decide, at platform device instantiation time, which region of queue SRAM can be used by which queue, and take static allocations for things like the crypto unit into account. (This is just one form of that idea, there are many different variations.) That way, you can _guarantee_ that you'll always have enough SRAM to be able to use the functionality that is exposed on the board you are running on (which is a desirable property, IMHO), which is something that you can't achieve with an allocator, as far as I can see. I'm not per se against the allocator, I just think that there are problems (running out of SRAM, fragmentation) that can't be solved by the allocator alone (SRAM users have to be aware which other SRAM users there are in the system, while the idea of the allocator is to insulate these users from each other), and any solution that solves those two problems IMHO also automatically solves the problem that the allocator is trying to solve. - 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: [1/1 take 2] Unified socket storage. (with small bench).
On Wed, May 09, 2007 at 03:02:00AM -0700, David Miller ([EMAIL PROTECTED]) wrote: From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Wed, 9 May 2007 13:57:40 +0400 That is only because we have very different way of working with udp. In udp hash table we can have multiple sockets bound to different ip addresses, but with the same port, so it will be placed into the same hash chain. With trie each socket will have differnet key, since addresses are different (or bound device number), so it automatically fixes problem with broken hash for udp (which is a bit fixed with extended hashing). Yes it is power of trie. So connection rates are interesting, but what about raw lookup performance? Last time this topic came up you went into some cave when you looked at the trie lookup assembly and compared it to hash. :) Sky was bluer and grass was greener that days... We discussed raw trie with completely different lookup algo (32 bits keys only, 32 checks per lookup), current implementation (and that one in previous patchset) is a serious step further. It does make more memory references than hash by definition, and we need to figure out whether that matters enough or not. Due to algorithm changes, on each new level we get upto 256 nodes which can store a pointer to data, so usual number of lookups should be 3 (max 4) for the current key organization. One of the worst cases is when the same source and destination address are used, but with different ports (like in shown example), in that case upto 8 lookups can be performed. We can even tune key organization to put fields known to be different first (admin can setup some kind of a policy on bootup/runtime) or perform non-destructive hashing (exchange bits in the key according to some law, like change first bit and the last one), which will speedup lookup, but that looks more like a ugly mental exercises and should not be considered in tests for now. -- Evgeniy Polyakov - 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 7/9] lguest: the net driver
[EMAIL PROTECTED] wrote:
+ if (desc-features LGUEST_NET_F_NOCSUM)
+ dev-features |= NETIF_F_NO_CSUM;
Any reason why you're using NO_CSUM here instead of HW_CSUM?
Practically there is no difference but NO_CSUM could be treated
differently in future and I'm not sure whether such changes would
be desirable in this driver (i.e., not even generating a partial
checksum).
Also, there doesn't seem to be any passing of metadata to the
backend which means that neither NO_CSUM/HW_CSUM can work if
somebody needs to look at the checksum field. You could use
IP_CSUM if you do the same hack on the backend that Xen does.
Otherwise you'll have to make do with no checksum offload at all.
I think you'd also need a change_mtu function if the SG feature
is going to be of some use since the default Ethernet one limits
the MTU to 1500.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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 3/3] AFS: Implement basic file write support
Andrew Morton [EMAIL PROTECTED] wrote:
+ BUG_ON(i_size 0x); // TODO: use 64-bit store
You're sure this isn't user-triggerable?
Hmmm... I'm not. I'll whip up a patch for this.
kmap_atomic() could be used here and is better.
Yeah. It used to have something that slept in the middle of it, but that's no
longer there. I'll add to the patch.
We have this zero_user_page() thing heading in which could perhaps be used
here also.
Okay. I'll have a look at it once it's there.
+ ASSERTRANGE(wb-first, =, index, =, wb-last);
wow.
:-)
The assertions I've put in have been very useful.
+ set_page_dirty(page);
+
+ if (PageDirty(page))
+ _debug(dirtied);
+
+ return 0;
+}
One would normally run mark_inode_dirty() after any i_size_write()?
Not in this case, I assume, because set_page_dirty() ultimately calls
__mark_inode_dirty(), but I could be wrong.
We can invalidate pages and we can truncate them and we can clean them.
But here we have a new operation, killing. I wonder what that is.
I can call it invalidation if you like, though that name is already reserved
as it were:-/ I suppose it might actually make sense for me to call
invalidatepage() myself.
+ if (wbc-sync_mode != WB_SYNC_NONE)
+ wait_on_page_writeback(page);
Didn't the VFS already do that?
I'm not entirely sure. Looking at generic_writepages(), I guess so. I'll
patch it out.
+ if (PageWriteback(page) || !PageDirty(page)) {
+ unlock_page(page);
+ return 0;
+ }
And some of that?
Yeah. Seems so. I'll patch that out too.
What I'd like to do is ditch writepage() entirely - I'm not sure it's entirely
necessary with the availability of writepages() - but I'll look at that
another time.
I have this vague prehistoric memory that something can go wrong at the VFS
level if the address_space writes back more pages than it was asked to.
But I forget what the issue was and it would be silly to have an issue
with that anyway. Something to keep an eye out for.
Okay.
Thanks for the 'cherry-pick'. I'll hopefully have a revision patch for you
soon.
David
-
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: D-Link DFE-580TX 4 port NIC problems
On Wed, 9 May 2007 12:01:42 +0200 Mario Doering [EMAIL PROTECTED] wrote: Hello, we have a D-Link DFE-580TX 4 port network card in our main router. It works pretty well most of the time, even though an error message pops up in dmesg every now and then (sometimes once a day sometimes once every few hours). But every few weeks those error messages increase rapidly, spamming dmesg. When this happens the system does not react anymore and pushing the reset button is the only option left. I googled around and found out that other users have same problem, but no solution to this. Part of the message log is located here: http://test.dedenet.de/messages.gz or http://test.dedenet.de/messages.txt uname -a Linux router1 2.6.19-gentoo-r5 #1 Sat Feb 17 17:04:03 CET 2007 i686 AMD Athlon(tm) XP AuthenticAMD GNU/Linux driver: [ 17.364707] sundance.c:v1.2 11-Sep-2006 Written by Donald Becker [ 17.364711] http://www.scyld.com/network/sundance.html [ 17.364844] ACPI: PCI Interrupt :03:04.0[A] - GSI 17 (level, low) - IRQ 17 [ 17.365396] eth1: D-Link DFE-580TX 4 port Server Adapter at 0001bc00, 00:0d:88:cc:a5:f0, IRQ 17. [ 17.366350] eth1: MII PHY found at address 1, status 0x7829 advertising 01e1. [ 17.676491] ACPI: PCI Interrupt :03:05.0[A] - GSI 18 (level, low) - IRQ 18 [ 17.676912] eth2: D-Link DFE-580TX 4 port Server Adapter at 0001b800, 00:0d:88:cc:a5:f1, IRQ 18. [ 17.677864] eth2: MII PHY found at address 1, status 0x7809 advertising 01e1. [ 17.987730] ACPI: PCI Interrupt :03:06.0[A] - GSI 19 (level, low) - IRQ 16 [ 17.988107] eth3: D-Link DFE-580TX 4 port Server Adapter at 0001b400, 00:0d:88:cc:a5:f2, IRQ 16. [ 17.989059] eth3: MII PHY found at address 1, status 0x7829 advertising 01e1. [ 18.298910] ACPI: PCI Interrupt :03:07.0[A] - GSI 16 (level, low) - IRQ 19 [ 18.299320] eth4: D-Link DFE-580TX 4 port Server Adapter at 0001b000, 00:0d:88:cc:a5:f3, IRQ 19. [ 18.300272] eth4: MII PHY found at address 1, status 0x7809 advertising 01e1. No such error message appears for about 7-10 days after a reboot. Maybe there is some kind of buffer running full? Do you need any additional info? Please CC me :-) (cc netdev) - 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] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, 9 May 2007 11:35:03 +0200, Marcus Better wrote: Lennert Buytenhek wrote: Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver. 1) Development _should_ happen in small individually-manageable steps. It's wrong to delay integration of the new IXP4xx eth driver just because it's not yet LE-compatible. 2) LE Debian/ARM users do have alternatives: they can use USB-Ethernet adapters, for instance. /Mikael - 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 3/3] AFS: Implement basic file write support
On Wed, 09 May 2007 11:25:47 +0100 David Howells [EMAIL PROTECTED] wrote: + set_page_dirty(page); + + if (PageDirty(page)) + _debug(dirtied); + + return 0; +} One would normally run mark_inode_dirty() after any i_size_write()? Not in this case, I assume, because set_page_dirty() ultimately calls __mark_inode_dirty(), but I could be wrong. set_page_dirty() will set I_DIRTY_PAGES only. ie: the inode has dirty pagecache data. To tell the VFS that the inode itself is dirty one needs to run mark_inode_dirty(). Or maybe mark_inode_dirty_sync() but I can never for the life of me remember what that thing does. - 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] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, 9 May 2007 11:35:03 +0200, Marcus Better wrote: Lennert Buytenhek wrote: Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver. 1) Development _should_ happen in small individually-manageable steps. It's wrong to delay integration of the new IXP4xx eth driver just because it's not yet LE-compatible. True. 2) LE Debian/ARM users do have alternatives: they can use USB-Ethernet adapters, for instance. In case of Freecom FSG-3, that would be four USB-ethernet adapters. With the cost roughly half of the cost of the whole device. And all USB-ports occupied. Provided you don't use them for something else. Someone could ask why has this device four mice connected? :) (for someone who doesn't work much with computers, a USB-ISDN or USB-ethernet adapter looks just like a mouse). And yet another viable alternative is to use a totally different device which is fully supported under Linux or another system, right? :) -- Tomasz Chmielewski http://wpkg.org - 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] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, May 09, 2007 at 11:35:03AM +0200, Marcus Better wrote: Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver. There's a crowd of users running Linux on TCP offload capable cards, and they need TCP offload support in Linux. The people who need a LE network driver can use Christian's driver, as Christian's driver works in LE just fine. The people who care about LE support can add LE support to the driver that Krzysztof wrote. I don't think that not supporting LE is a reason not to merge Krzysztof's driver. Don't make supporting LE systems Krzysztof's problem. Krzysztof has written an excellent driver, and while it would be 100% Debian style to reject his driver just because it doesn't support LE[*], thankfully, Linux is not Debian. Please don't turn Linux into Debian. [*] And if he were to complain about this, he would get slapped with the standard Our priorities are our users and free software Debian Social Contract rhetoric -- thank $DEITY we don't have a Linux Kernel Social Contract with the same bullshit in it. - 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 3/3] AFS: Implement basic file write support
Andrew Morton [EMAIL PROTECTED] wrote: set_page_dirty() will set I_DIRTY_PAGES only. ie: the inode has dirty pagecache data. To tell the VFS that the inode itself is dirty one needs to run mark_inode_dirty(). But what's the difference in this case? I don't need to write the inode back per se, and the inode attributes can be updated by the mechanism of data storage. David - 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] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, May 09, 2007 at 12:35:40PM +0200, Mikael Pettersson wrote: Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver. 1) Development _should_ happen in small individually-manageable steps. It's wrong to delay integration of the new IXP4xx eth driver just because it's not yet LE-compatible. Exactly. 2) LE Debian/ARM users do have alternatives: they can use USB-Ethernet adapters, for instance. Or just use Christian's driver. - 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: smp_affinity, MSI-X and 2.6.21.1
That's true, but we are talking about software state so in some sense
it might be better that the affinity-to-be is reported to the user in
this case.
Delayed register updates are an implementation detail the user does
not need to know about here.
This patch should fix it.
-Andi
Report the pending irq if available in smp_affinity
Otherwise smp_affinity would only update after the next interrupt
on x86 systems.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux/kernel/irq/proc.c
===
--- linux.orig/kernel/irq/proc.c
+++ linux/kernel/irq/proc.c
@@ -19,7 +19,14 @@ static struct proc_dir_entry *root_irq_d
static int irq_affinity_read_proc(char *page, char **start, off_t off,
int count, int *eof, void *data)
{
- int len = cpumask_scnprintf(page, count, irq_desc[(long)data].affinity);
+ struct irq_desc *desc = irq_desc + (long)data;
+ cpumask_t *mask = desc-affinity;
+ int len;
+#ifdef CONFIG_GENERIC_PENDING_IRQ
+ if (desc-status IRQ_MOVE_PENDING)
+ mask = desc-pending_mask;
+#endif
+ len = cpumask_scnprintf(page, count, *mask);
if (count - len 2)
return -EINVAL;
-
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 7/9] lguest: the net driver
On Wed, 2007-05-09 at 20:12 +1000, Herbert Xu wrote: [EMAIL PROTECTED] wrote: + if (desc-features LGUEST_NET_F_NOCSUM) + dev-features |= NETIF_F_NO_CSUM; Any reason why you're using NO_CSUM here instead of HW_CSUM? Practically there is no difference but NO_CSUM could be treated differently in future and I'm not sure whether such changes would be desirable in this driver (i.e., not even generating a partial checksum). Hi Herbert, NO_CSUM because it really doesn't need a checksum. The LGUEST_NET_F_NOCSUM is only set for local inter-guest networking. If some guest were to route the packets outside the machine, this would be an issue, though (don't do that). Also, there doesn't seem to be any passing of metadata to the backend which means that neither NO_CSUM/HW_CSUM can work if somebody needs to look at the checksum field. You could use IP_CSUM if you do the same hack on the backend that Xen does. Otherwise you'll have to make do with no checksum offload at all. Yeah, definitely good future work. This is far simpler: external-facing networks don't get marked with the LGUEST_NET_F_NOCSUM but set. KVM is going to have a paravirt network driver too: it'd be nice to share code here. I think you'd also need a change_mtu function if the SG feature is going to be of some use since the default Ethernet one limits the MTU to 1500. Indeed, that would be a new feature, and is certainly a consideration for more efficient inter-guest networking. However, I consider that somewhat cheating: it's nice to know that 1500 doesn't suck too hard. Remember, Features kill puppies! 8) Thanks, Rusty. - 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 7/9] lguest: the net driver
Hi Rusty:
On Wed, May 09, 2007 at 09:55:25PM +1000, Rusty Russell wrote:
NO_CSUM because it really doesn't need a checksum. The
LGUEST_NET_F_NOCSUM is only set for local inter-guest networking. If
some guest were to route the packets outside the machine, this would be
an issue, though (don't do that).
While I can see that this is good in keeping things simple, I think
it's something that you want to be able to support since the user
may wish to setup a guest as a firewall appliance which would involve
passing packets from another guest to the outside world.
Indeed, that would be a new feature, and is certainly a consideration
for more efficient inter-guest networking. However, I consider that
somewhat cheating: it's nice to know that 1500 doesn't suck too hard.
Remember, Features kill puppies! 8)
Heh :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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 7/9] lguest: the net driver
On Wed, 2007-05-09 at 22:00 +1000, Herbert Xu wrote: Hi Rusty: On Wed, May 09, 2007 at 09:55:25PM +1000, Rusty Russell wrote: NO_CSUM because it really doesn't need a checksum. The LGUEST_NET_F_NOCSUM is only set for local inter-guest networking. If some guest were to route the packets outside the machine, this would be an issue, though (don't do that). While I can see that this is good in keeping things simple, I think it's something that you want to be able to support since the user may wish to setup a guest as a firewall appliance which would involve passing packets from another guest to the outside world. Indeed, you understand the tradeoff. The example launcher could have an option not to set the LGUEST_NET_F_NOCSUM in this case. That said, one significant purpose of lguest is to serve as an example of how to do things. So if you feel really strongly that there's a Right Way, we could look at the patch... Thanks, Rusty. - 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
Bluetooth fixes for 2.6.22
Hi Dave, here are some minor additional fixes that should go into 2.6.22 before Linus closes the merge window. Regards Marcel Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git This will update the following files: drivers/bluetooth/hci_ldisc.c | 10 +- drivers/bluetooth/hci_uart.h |5 +++-- net/bluetooth/hidp/core.c | 10 +- 3 files changed, 17 insertions(+), 8 deletions(-) through these ChangeSets: Commit: 19242490ea04586d581113dd8895ba2ebed75c9b Author: Marcel Holtmann [EMAIL PROTECTED] Wed, 09 May 2007 09:15:45 +0200 [Bluetooth] Fix unintentional fall-through in HCI line discipline A trivial fix to (what looks like) an unintentional fall-through in the HCI line discipline. Signed-off-by: Ohad Ben-Cohen [EMAIL PROTECTED] Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] Commit: d4c2c832c4a2247a9e9a320d4da4532a6ebfebb3 Author: Marcel Holtmann [EMAIL PROTECTED] Wed, 09 May 2007 09:15:40 +0200 [Bluetooth] Fix NULL pointer dereference in HCI line discipline Normally a serial Bluetooth device is opened, TIOSETD'ed to N_HCI line discipline, HCIUARTSETPROTO'ed and finally closed. In case the device fails to HCIUARTSETPROTO, closing it produces a NULL pointer dereference. Signed-off-by: Ohad Ben-Cohen [EMAIL PROTECTED] Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] Commit: ecbe531f666e08d41eb6f0ef8e2eb8dca5aa99d5 Author: Marcel Holtmann [EMAIL PROTECTED] Wed, 09 May 2007 09:15:35 +0200 [Bluetooth] Add HCIUARTGETDEVICE support for HCI line discipline Adding HCIUARTGETDEVICE makes it possible to get the HCI device number that is attached to a given serial device. This is required during the initialization process of some Bluetooth chips. Signed-off-by: Ohad Ben-Cohen [EMAIL PROTECTED] Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] Commit: 30168f98fb48b3cce14900c153781cef41eea363 Author: Marcel Holtmann [EMAIL PROTECTED] Wed, 09 May 2007 09:15:30 +0200 [Bluetooth] Switch to using input_dev-dev.parent In preparation for struct class_device - struct device input core conversion, switch to using input_dev-dev.parent when specifying device position in sysfs tree. Also, do not access input_dev-private directly, use helpers and do not use kfree() on input device, use input_free_device() instead. Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] - 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] AFS: Write support fixes
AFS write support fixes:
(1) Support large files using the 64-bit file access operations if available
on the server.
(2) Use kmap_atomic() rather than kmap() in afs_prepare_page().
(3) Don't do stuff in afs_writepage() that's done by the caller.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
fs/afs/afs_fs.h |2
fs/afs/fsclient.c | 217 -
fs/afs/write.c| 14 +--
3 files changed, 216 insertions(+), 17 deletions(-)
diff --git a/fs/afs/afs_fs.h b/fs/afs/afs_fs.h
index 2198006..d963ef4 100644
--- a/fs/afs/afs_fs.h
+++ b/fs/afs/afs_fs.h
@@ -31,6 +31,8 @@ enum AFS_FS_Operations {
FSGETVOLUMEINFO = 148, /* AFS Get root volume information */
FSGETROOTVOLUME = 151, /* AFS Get root volume name */
FSLOOKUP= 161, /* AFS lookup file in directory */
+ FSFETCHDATA64 = 65537, /* AFS Fetch file data */
+ FSSTOREDATA64 = 65538, /* AFS Store file data */
};
enum AFS_FS_Errors {
diff --git a/fs/afs/fsclient.c b/fs/afs/fsclient.c
index a552699..8817076 100644
--- a/fs/afs/fsclient.c
+++ b/fs/afs/fsclient.c
@@ -293,9 +293,33 @@ static int afs_deliver_fs_fetch_data(struct afs_call *call,
case 0:
call-offset = 0;
call-unmarshall++;
+ if (call-operation_ID != FSFETCHDATA64) {
+ call-unmarshall++;
+ goto no_msw;
+ }
- /* extract the returned data length */
+ /* extract the upper part of the returned data length of an
+* FSFETCHDATA64 op (which should always be 0 using this
+* client) */
case 1:
+ _debug(extract data length (MSW));
+ ret = afs_extract_data(call, skb, last, call-tmp, 4);
+ switch (ret) {
+ case 0: break;
+ case -EAGAIN: return 0;
+ default:return ret;
+ }
+
+ call-count = ntohl(call-tmp);
+ _debug(DATA length MSW: %u, call-count);
+ if (call-count 0)
+ return -EBADMSG;
+ call-offset = 0;
+ call-unmarshall++;
+
+ no_msw:
+ /* extract the returned data length */
+ case 2:
_debug(extract data length);
ret = afs_extract_data(call, skb, last, call-tmp, 4);
switch (ret) {
@@ -312,7 +336,7 @@ static int afs_deliver_fs_fetch_data(struct afs_call *call,
call-unmarshall++;
/* extract the returned data */
- case 2:
+ case 3:
_debug(extract data);
if (call-count 0) {
page = call-reply3;
@@ -331,7 +355,7 @@ static int afs_deliver_fs_fetch_data(struct afs_call *call,
call-unmarshall++;
/* extract the metadata */
- case 3:
+ case 4:
ret = afs_extract_data(call, skb, last, call-buffer,
(21 + 3 + 6) * 4);
switch (ret) {
@@ -349,7 +373,7 @@ static int afs_deliver_fs_fetch_data(struct afs_call *call,
call-offset = 0;
call-unmarshall++;
- case 4:
+ case 5:
_debug(trailer);
if (skb-len != 0)
return -EBADMSG;
@@ -381,6 +405,56 @@ static const struct afs_call_type afs_RXFSFetchData = {
.destructor = afs_flat_call_destructor,
};
+static const struct afs_call_type afs_RXFSFetchData64 = {
+ .name = FS.FetchData64,
+ .deliver= afs_deliver_fs_fetch_data,
+ .abort_to_error = afs_abort_to_error,
+ .destructor = afs_flat_call_destructor,
+};
+
+/*
+ * fetch data from a very large file
+ */
+static int afs_fs_fetch_data64(struct afs_server *server,
+ struct key *key,
+ struct afs_vnode *vnode,
+ off_t offset, size_t length,
+ struct page *buffer,
+ const struct afs_wait_mode *wait_mode)
+{
+ struct afs_call *call;
+ __be32 *bp;
+
+ _enter();
+
+ ASSERTCMP(length, , ULONG_MAX);
+
+ call = afs_alloc_flat_call(afs_RXFSFetchData64, 32, (21 + 3 + 6) * 4);
+ if (!call)
+ return -ENOMEM;
+
+ call-key = key;
+ call-reply = vnode;
+ call-reply2 = NULL; /* volsync */
+ call-reply3 = buffer;
+ call-service_id = FS_SERVICE;
+ call-port = htons(AFS_FS_PORT);
+ call-operation_ID = FSFETCHDATA64;
+
+ /* marshall the parameters */
+ bp = call-request;
+ bp[0] = htonl(FSFETCHDATA64);
+ bp[1] = htonl(vnode-fid.vid);
+ bp[2] = htonl(vnode-fid.vnode);
+ bp[3] = htonl(vnode-fid.unique);
+
Re: [PATCH] sched: Optimize return value of qdisc_restart
On Wed, 2007-09-05 at 01:12 -0700, David Miller wrote: Something this evening is obviously making it impossible for my brain to understand this function and your patch, so I'm going to sleep on it and try again tomorrow :-) It is one of those areas that are hard to size-up in a blink;- Gut-feeling: It doesnt sit right with me as well. With (2.6.18-rxX++) QDISC_RUNNING changes that mean only one of N CPUs will be dequeueing while the N-1 maybe enqueueing concurently. All N CPUs contend for the queue lock; and theres a possible window between releasing the queue lock by the dequeuer-CPU and enqueuer-CPU for a race. The dequeuer-CPU entering one last time helps. Krishna, you probably saw this wasted entry into qdisc under low traffic conditions with more than likely only one CPU sending, am i correct? Under heavier traffic when we have multiple CPUs funneling to the same device, that entry is not really a waste because we endup only go in once per X number of packets enqueued on the qdisc and that check is absolutely necessary because a different CPU may have enqueued while you were not looking. In the case of low traffic, X=1 - so it is a waste there albeit a necessary one. cheers, jamal - 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 (take 2)] vlan: lockdep class for ppp _xmit_lock Re: ppp_generic: fix lockdep warning
On Wed, May 09, 2007 at 02:32:24AM -0700, David Miller wrote:
From: Jarek Poplawski [EMAIL PROTECTED]
Date: Wed, 9 May 2007 11:35:37 +0200
After rethinking there is the 3-rd way (as usual):
c) vlan should use different lockdep lock subclasses or
classes for different types of devices, used at the same
time.
Perhaps we should just bite the bullet and use a seperate
unique lock class for -_xmit_lock of each device type.
We are going to find more cases like this one, for sure.
Theoretically subclasses are intended for this, and there
are 6 free places still. Practically lockdep treats subclasses
differently sometimes (e.g., now, it seems, it cannot see a real
recursion error inside a subclass). So, it's mainly a problem
of some static memory wasting or saving (unless it should be
subclassed yet - then no question).
Here is your way alternative, preferred version - I hope Yuriy
isn't bored with this testing yet!
Of course, I see nothing against you or somebody else doing
or re-doing this all as needed.
Regards,
Jarek P.
--- (take 2)
This patch's aim is to let lockdep see ppp devs as different
from others (default), and it's OK to take: _xmit_lock of vlan
and _xmit_lock of ppp with reverse order provided vlan _xmit_locks
are bound to different devs (ppp and e.g. eth).
===
[ INFO: possible circular locking dependency detected ]
2.6.21-rc6-mm1 #4
---
pppd/14305 is trying to acquire lock:
(vlan_netdev_xmit_lock_key){-...}, at: [8022f90b]
dev_queue_xmit+0x26b/0x300
but task is already holding lock:
(pch-downl#2){-+..}, at: [80388d3c] ppp_push+0x5f/0xa7
which lock already depends on the new lock.
The final idea to use separate classes by David Miller.
Reported tested by: Yuriy N. Shkandybin [EMAIL PROTECTED]
Cc: Ben Greear [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Michal Ostrowski [EMAIL PROTECTED]
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp 2.6.21-git7-/net/8021q/vlan.c 2.6.21/net/8021q/vlan.c
--- 2.6.21-git7-/net/8021q/vlan.c 2007-05-01 12:43:39.0 +0200
+++ 2.6.21/net/8021q/vlan.c 2007-05-09 14:46:12.0 +0200
@@ -376,6 +376,8 @@ static void vlan_transfer_operstate(cons
*/
static struct lock_class_key vlan_netdev_xmit_lock_key;
+/* pppoe uses two different kinds of _xmit_lock for ppp eth */
+static struct lock_class_key vlan_ppp_xmit_lock_key;
/* Attach a VLAN device to a mac address (ie Ethernet Card).
* Returns the device that was created, or NULL if there was
@@ -535,7 +537,12 @@ static struct net_device *register_vlan_
if (register_netdevice(new_dev))
goto out_free_newdev;
- lockdep_set_class(new_dev-_xmit_lock, vlan_netdev_xmit_lock_key);
+ if (unlikely(real_dev-type == ARPHRD_PPP))
+ lockdep_set_class(new_dev-_xmit_lock,
+ vlan_ppp_xmit_lock_key);
+ else
+ lockdep_set_class(new_dev-_xmit_lock,
+ vlan_netdev_xmit_lock_key);
new_dev-iflink = real_dev-ifindex;
vlan_transfer_operstate(real_dev, new_dev);
-
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] AFS: Further write support fixes
Further fixes for AFS write support:
(1) The afs_send_pages() outer loop must do an extra iteration if it ends
with 'first == last' because 'last' is inclusive in the page set
otherwise it fails to send the last page and complete the RxRPC op under
some circumstances.
(2) Similarly, the outer loop in afs_pages_written_back() must also do an
extra iteration if it ends with 'first == last', otherwise it fails to
clear PG_writeback on the last page under some circumstances.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
fs/afs/rxrpc.c |2 +-
fs/afs/write.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
index 04189c4..1b36f45 100644
--- a/fs/afs/rxrpc.c
+++ b/fs/afs/rxrpc.c
@@ -294,7 +294,7 @@ int afs_send_pages(struct afs_call *call, struct msghdr
*msg, struct kvec *iov)
put_page(pages[loop]);
if (ret 0)
break;
- } while (first last);
+ } while (first = last);
_leave( = %d, ret);
return ret;
diff --git a/fs/afs/write.c b/fs/afs/write.c
index aa03d43..67ae4db 100644
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -669,7 +669,7 @@ void afs_pages_written_back(struct afs_vnode *vnode, struct
afs_call *call)
pagevec_init(pv, 0);
do {
- _debug(attach %lx-%lx, first, last);
+ _debug(done %lx-%lx, first, last);
count = last - first + 1;
if (count PAGEVEC_SIZE)
@@ -701,7 +701,7 @@ void afs_pages_written_back(struct afs_vnode *vnode, struct
afs_call *call)
}
__pagevec_release(pv);
- } while (first last);
+ } while (first = last);
_leave();
}
-
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] AF_RXRPC: Reduce debugging noise.
Reduce debugging noise generated by AF_RXRPC.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
net/rxrpc/ar-peer.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rxrpc/ar-peer.c b/net/rxrpc/ar-peer.c
index ce08b78..90fa107 100644
--- a/net/rxrpc/ar-peer.c
+++ b/net/rxrpc/ar-peer.c
@@ -59,14 +59,14 @@ static void rxrpc_assess_MTU_size(struct rxrpc_peer *peer)
ret = ip_route_output_key(rt, fl);
if (ret 0) {
- kleave( [route err %d], ret);
+ _leave( [route err %d], ret);
return;
}
peer-if_mtu = dst_mtu(rt-u.dst);
dst_release(rt-u.dst);
- kleave( [if_mtu %u], peer-if_mtu);
+ _leave( [if_mtu %u], peer-if_mtu);
}
/*
-
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] IPROUTE: Modify tc for new PRIO multiqueue behavior
On Tue, 2007-05-08 at 09:28 -0400, jamal wrote: Those virtual devices you have right now. They are a hack that needs to go at some point. Actually, if we're talking about mac80211, the master device we have that does the qos stuff must go, but the other virtual devices need to stay for WDS/AP and a lot of other combinations. Just to clear up some possible confusion. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lennert Buytenhek wrote: The people who need a LE network driver can use Christian's driver, as Christian's driver works in LE just fine. The people who care about LE support can add LE support to the driver that Krzysztof wrote. I don't think that not supporting LE is a reason not to merge Krzysztof's driver. Don't make supporting LE systems Krzysztof's problem. Krzysztof has written an excellent driver, and while it would be 100% Debian style to reject his driver just because it doesn't support LE[*], thankfully, Linux is not Debian. Please don't turn Linux into Debian. I am using the ixp425 on the avila from gateworks. It only has 16 MB of flash built in. We needed to squeeze a production and a failsafe linux inside that so debian was not an option. I found intel's original drivers horrible to read, maintain, and use. We are using Cristian's driver (rev 0.2.1) and are preparing to go to his latest for the crypto support. I only had one bug in 0.2.1, which is fixed in later versions. I would love to see mail line support for this device, including the ethernet ports and the crypto capabilities. We run in big endian despite the extra difficulty in toolset setup and finding lots of brain0-damaged-designed-for-x86 code. We already can use up the CPU when we have the mini-pci slots populated with 802.11g radios and the ethernet port in use. Swapping packets would kill us. Never mind if we do any kind of software based crypto! For those of us in the embedded space, performance matters. Big endian is the natural setup for the NPEs on this hardware according to the intel documentation. Please don't stop this driver from moving forward so that a few folks can run their hardware in slow mode. -Ack - 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] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On 9 May 2007, at 15:22, David Acker wrote: Big endian is the natural setup for the NPEs on this hardware according to the intel documentation. Please don't stop this driver from moving forward so that a few folks can run their hardware in slow mode. No-one is saying that this driver should not be mainlined before it has LE support. All that I said was: Personally I'd like LE ethernet tested and working before we push. The alternative would be to explicitly state in Kconfig that LE arm is broken with this driver, so that this could be fixed later. Please can we not blow this out of proportion, it really isn't that big a deal. The irony is that fixing Krzysztof's driver to work on LE will probably be quite easy, given that we already have a working LE driver from Christian. Michael-Luke PS: It really isn't just 'a few folks' - at NSLU2-Linux we have 5000 people who have downloaded Debian/LE for NSLU2 and are currently using Christian's driver with great success. We would just like to replicate that support with this new driver. - 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] sched: Optimize return value of qdisc_restart
Hi Jamal, J Hadi Salim [EMAIL PROTECTED] wrote on 05/09/2007 06:26:43 PM: On Wed, 2007-09-05 at 01:12 -0700, David Miller wrote: Something this evening is obviously making it impossible for my brain to understand this function and your patch, so I'm going to sleep on it and try again tomorrow :-) It is one of those areas that are hard to size-up in a blink;- Gut-feeling: It doesnt sit right with me as well. With (2.6.18-rxX++) QDISC_RUNNING changes that mean only one of N CPUs will be dequeueing while the N-1 maybe enqueueing concurently. All N Concurrently is not possible, since everyone needs the queue_lock to add/delete. Did I misunderstand your comment ? CPUs contend for the queue lock; and theres a possible window between releasing the queue lock by the dequeuer-CPU and enqueuer-CPU for a race. The dequeuer-CPU entering one last time helps. The dev-queue_lock is held by both enqueue'r and dequeue'r (though the dequeue'r drops it before calling xmit). But once the dequeue'r re-gets the lock, it is guaranteed that no one else has the lock Other CPU's trying to add will block on the lock, or if they have already added by getting the lock for a short time while my CPU was doing the xmit, then their qdisc_run returns doing nothing as RUNNING is true. Since I am holding a lock in these two changed areas till I return back to __qdisc_run (which clears the RUNNING bit) and then drop the lock, there is no way packets can be on the queue while I falsely return 0, or no packets on the queue while I falsely return -1. I hope my explanation was not confusing. Krishna, you probably saw this wasted entry into qdisc under low traffic conditions with more than likely only one CPU sending, am i correct? Under heavier traffic when we have multiple CPUs funneling to Actually, I have never seen this problem, just code reading while trying to implement something else in this area, for which I plan to bug Dave in a few days. Thanks, - KK the same device, that entry is not really a waste because we endup only go in once per X number of packets enqueued on the qdisc and that check is absolutely necessary because a different CPU may have enqueued while you were not looking. In the case of low traffic, X=1 - so it is a waste there albeit a necessary one. cheers, jamal - 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 00/17] sky2 update for 2.6.22
On Wed, 09 May 2007 00:16:48 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: Patches are against netdev-2.6 upstream code branch. This includes a several bug fixes, and code cleanup to use standard functions. There are a couple of PCI changes. One bug fix, and moving common code in PCI base. The standard development process is: * new code gets pushed to me during 2.6.X-rc * that code is auto-propagated to akpm's -mm tree for additional exposure * merge window opens * I push upstream That ensures code gets at least /some/ additional review, testing, settling time. Sorry for the late merge, but between the closing of OSDL office and the fixing of critical bugs the other stuff got pushed into the next release bin and wasn't really ready until now. This is a late date to be expecting stuff to be pushed straight into 2.6.22. Then hold it for 2.6.23. Additionally, the rule for creating patches is: diff against latest vanilla linux-2.6.git tree, unless dependencies exist in netdev. After the merge window opens, #upstream is often empty or even a bit behind upstream, since Linus pulls that. One patch wouldn't have applied unless the recent patch that you accepted was included. Jeff -- Stephen Hemminger [EMAIL PROTECTED] - 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] atl1: add netconsole support
Copied from b44 driver, but it works:
netconsole: device eth0 not up yet, forcing it
atl1: eth0 link is up 100 Mbps full duplex
netconsole: network logging started
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
---
drivers/net/atl1/atl1_main.c | 12
1 file changed, 12 insertions(+)
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -2046,6 +2046,15 @@ static int atl1_close(struct net_device *netdev)
return 0;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void atl1_poll_controller(struct net_device *netdev)
+{
+ disable_irq(netdev-irq);
+ atl1_intr(netdev-irq, netdev);
+ enable_irq(netdev-irq);
+}
+#endif
+
/*
* If TPD Buffer size equal to 0, PCIE DMAR_TO_INT
* will assert. We do soft reset 0x1400=1 according
@@ -2198,6 +2207,9 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
netdev-do_ioctl = atl1_ioctl;
netdev-tx_timeout = atl1_tx_timeout;
netdev-watchdog_timeo = 5 * HZ;
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ netdev-poll_controller = atl1_poll_controller;
+#endif
netdev-vlan_rx_register = atl1_vlan_rx_register;
netdev-vlan_rx_add_vid = atl1_vlan_rx_add_vid;
netdev-vlan_rx_kill_vid = atl1_vlan_rx_kill_vid;
-
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
Enable netem in my Linux box
Hi: My Linux box has CentOS5 installed. But I could not run tc command with any netem parameters in command line. as shown in web site http://linux-net.osdl.org/index.php/Netem. I suspect, Netem was either not part of the installed OS or has not been enabled. Can you tell how to verified? When I type in rpm -qa I see only iproute-2.6.18-4.el5, do I need iproute2? Can you tell me how to update my Linux kernel to include netem functionality. Thanks, Koon-Wah. - 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] sched: Optimize return value of qdisc_restart
Krishna, On Wed, 2007-09-05 at 20:17 +0530, Krishna Kumar2 wrote: Concurrently is not possible, since everyone needs the queue_lock to add/delete. Did I misunderstand your comment ? I think so, more below where you explain it: The dev-queue_lock is held by both enqueue'r and dequeue'r (though the dequeue'r drops it before calling xmit). But once the dequeue'r re-gets the lock, it is guaranteed that no one else has the lock Other CPU's trying to add will block on the lock, or if they have already added by getting the lock for a short time while my CPU was That is how concurency is achieved on the queue. If you have N CPUs, N-1 could be queueing. Important to note, only one - that owns the QDISC_RUNNING can dequeue. doing the xmit, then their qdisc_run returns doing nothing as RUNNING is true. lack of ownership of QDISC_RUNNING is what makes them enqueuers. The CPU that owns it is the dequeuer. Since I am holding a lock in these two changed areas till I return back to __qdisc_run (which clears the RUNNING bit) and then drop the lock, there is no way packets can be on the queue while I falsely return 0, or no packets on the queue while I falsely return -1. If you relinquish yourself from being a dequeuer by letting go of RUNNING then it is possible during that short window one of the other N-1 CPUs could have been enqueueing; that packet will never be dequeued unless a new packet shows up some X amount of time later. I hope my explanation was not confusing. I hope what i described above helps. Off for about a day. CCing Herbert who last made changes to that area incase i missed something .. cheers, jamal PS:- Please dont use my temporary gmail account to respond; a reply-to will pick the right address (@cyberus.ca). - 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: SG_IO with 4k buffer size to iscsi sg device causes Bad page panic
-Original Message- From: Mike Christie [mailto:[EMAIL PROTECTED] Qi, Yanling wrote: Yeah, this problem should occur in the upstream open-iscsi iscsi code. open-iscsi works very similar to linux-scsi where it just sends pages around with sock-ops-sendpage, and it looks like sg uses __get_free_pages in RHEL's kernel and upstream it uses alloc_pages so unless there was a change in those functions or the network layer then we should have a similar problem. [Qi, Yanling] Mike, I tried the same test on a SLES10SP1 with open-iscsi driver (lk 2.6.16.37-0.23). It works fine. What happens is that both alloc_pages() and __get_free_pages() will set page_count to 1 for base page and sub-pages. Because page_count =1, the subpages will not be recycled. It seems the mm code has changed alloc_pages and __get_free_pages()'s behavior along the way from 2.6.9 to 2.6.16. Therefore, we don't have an issue in the upstream kernel and RHEL5. 0 page:81007f8da240 flags:0x01004000 mapping: mapcount:0 count:1 1 page:81007f8da278 flags:0x01004000 mapping: mapcount:0 count:1 2 page:81007f8da2b0 flags:0x01004000 mapping: mapcount:0 count:1 3 page:81007f8da2e8 flags:0x01004000 mapping: mapcount:0 count:1 4 page:81007f8da320 flags:0x01004000 mapping: mapcount:0 count:1 5 page:81007f8da358 flags:0x01004000 mapping: mapcount:0 count:1 6 page:81007f8da390 flags:0x01004000 mapping: mapcount:0 count:1 7 page:81007f8da3c8 flags:0x01004000 mapping: mapcount:0 count:1 Thanks, Yanling - 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 3/3] AFS: Implement basic file write support
On Wed, 09 May 2007 12:07:39 +0100 David Howells [EMAIL PROTECTED] wrote: Andrew Morton [EMAIL PROTECTED] wrote: set_page_dirty() will set I_DIRTY_PAGES only. ie: the inode has dirty pagecache data. To tell the VFS that the inode itself is dirty one needs to run mark_inode_dirty(). But what's the difference in this case? I don't need to write the inode back per se, and the inode attributes can be updated by the mechanism of data storage. Ah. Well if you don't need to write the inode back then sure, there shouldn't be a need to mark it dirty. That's what I was asking ;) - 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 1/1] Fix hang on IBM Token Ring PCMCIA card ejection
On Tue, 8 May 2007, Jeff Garzik wrote: ACK but does not apply Thanks. Some mailer trouble I guess - will resend via quilt. - Paul - 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] From: Paul Walmsley [EMAIL PROTECTED]
Ejecting a PCMCIA IBM Token Ring card that has not had its dev-open()
called will reliably trigger an uninitialized spinlock oops when
spinlock debugging is enabled. The system then hangs, occasionally
softlockup oopsing. Apparently ibmtr.c:tok_interrupt() doesn't expect
to be called before tok_open(), but tok_interrupt() gets called anyway
when the card is ejected. So, set an already-existing flag which
causes tok_interrupt() to bail out early upon card ejection. Tested by
inserting and removing the PCMCIA card several times.
Patch against 2.6.21-rc6.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
ibmtr_cs.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/pcmcia/ibmtr_cs.c b/drivers/net/pcmcia/ibmtr_cs.c
index 1060154..9359ca7 100644
--- a/drivers/net/pcmcia/ibmtr_cs.c
+++ b/drivers/net/pcmcia/ibmtr_cs.c
@@ -189,16 +189,20 @@ static void ibmtr_detach(struct pcmcia_device *link)
{
struct ibmtr_dev_t *info = link-priv;
struct net_device *dev = info-dev;
+ struct tok_info *ti = netdev_priv(dev);
DEBUG(0, ibmtr_detach(0x%p)\n, link);
+
+/*
+ * When the card removal interrupt hits tok_interrupt(),
+ * bail out early, so we don't crash the machine
+ */
+ti-sram_phys |= 1;
if (link-dev_node)
unregister_netdev(dev);
-
-{
- struct tok_info *ti = netdev_priv(dev);
- del_timer_sync((ti-tr_timer));
-}
+
+del_timer_sync((ti-tr_timer));
ibmtr_release(link);
--
-
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 06/17] sky2: advanced error reporting
On Tue, May 08, 2007 at 08:49:55PM -0700, Stephen Hemminger wrote: Use the kernel interfaces for advanced error reporting. This should be cleaner and clear up errors on boot. Hmm. I thought that the AER functions would eventually be handled by the struct pci_error_handlers callbacks, so that dev drivers wouldn't actually have code such as + pci_read_config_dword(pdev, pos + PCI_ERR_UNCOR_STATUS, status); + pci_read_config_dword(pdev, pos + PCI_ERR_UNCOR_SEVER, mask); in them. But perhaps I haven't studed what this drivr is trying to do; nor have I really kept track of the aer code. --linas - 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 10/12] drivers: PMC MSP71xx ethernet driver
Thanks for the feedback Jeff. I have made all modifications but I have one
question regarding the SKB recycling.
Removing the backwards compatibility for the linux 2.4 eliminated the
badness in mspeth_skb_headerinit(). However there is still some SKB code
in mspeth_alloc_skb(). You didn't specifically comment on that, is it
acceptable?
We are reluctant to remove the SKB recycling code as it provides a
significant performance improvement.
Marc
Jeff Garzik wrote:
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
+#include linux/dma-mapping.h
+#include linux/platform_device.h
+#include net/xfrm.h
+#include asm/cpu-features.h
+#include msp_regs.h
+#include msp_regops.h
+#include msp_prom.h
+#include msp_int.h
+#elif LINUX_VERSION_CODE = KERNEL_VERSION(2,4,0)
+#include asm/r4kcache.h
+#include asm/brecis/prom.h
+#include asm/brecis/brecisint.h
+#include asm/brecis/brecisint.h
+#include asm/brecis/BrecisSysRegs.h
+#include brecis/msp.h
+#endif /* LINUX_VERSION_CODE */
+
+#include pmcmspeth.h
+
+/**
+ * The name of the card. Is used for messages and in the requests for
+ * io regions, irqs and dma channels, versions, etc. Also, various
other
+ * identifying character constants.
+ */
+static const char cardname[] = pmcmspeth;
+
+/**
+ * List of PHYs. Each MAC will have a certain number (maybe zero)
+ * PHYs hanging off the MDIO interface.
+ */
+static struct mspeth_phy *root_phy_dev = NULL;
+
+/* Debugging flags */
+static unsigned int mspeth_debug = MSPETH_DEBUG;
use netif_msg_init() and the bitmapped message flags. grep for
'netif_msg_' and 'msg_enable' in various drivers.
+/**
+ * Function prototypes
+ */
+
+/* Functions that get called by upper layers */
+static int mspeth_open(struct net_device *dev);
+static int mspeth_send_packet(struct sk_buff *skb,
+ struct net_device *dev);
+static void mspeth_tx_timeout(struct net_device *dev);
+static void mspeth_hard_restart_bh(unsigned long dev_addr);
+static int mspeth_close(struct net_device *dev);
+static struct net_device_stats *mspeth_get_stats(struct net_device
*dev);
+static void mspeth_set_multicast_list(struct net_device *dev);
+
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
+static irqreturn_t mspeth_interrupt(int irq, void *dev_id);
+#elif LINUX_VERSION_CODE = KERNEL_VERSION(2,4,0)
+static void mspeth_interrupt(int irq, void *dev_id, struct pt_regs
*regs);
+#endif
remove all kernel compat ifdefs
+ /* protect access with spin lock */
+ spin_lock_irqsave((phyptr-lock), flags);
+
+ while (__raw_readl(phyptr-memaddr + MSPPHY_MII_CTRL)
+ MD_CA_BUSY_BIT) {;}
+ __raw_writel(MD_CA_BUSY_BIT | phyptr-phyaddr 5 | phy_reg,
+ phyptr-memaddr + MSPPHY_MII_CTRL);
+ while (__raw_readl(phyptr-memaddr + MSPPHY_MII_CTRL)
+ MD_CA_BUSY_BIT) {;}
+ data = __raw_readl(phyptr-memaddr + MSPPHY_MII_DATA);
no infinite loops allowed
+ /* unlock */
+ spin_unlock_irqrestore((phyptr-lock), flags);
+
+ return data 0x;
+}
+
+static void
+mspphy_write(struct mspeth_phy *phyptr, int phy_reg, u32 data)
+{
+ unsigned long flags;
+
+ if (phyptr == NULL) {
+ printk(KERN_WARNING MSPETH(mspphy_write):
+ Cannot write to a NULL PHY!\n);
This is a BUG_ON() condition
+ /* protect access with spin lock */
+ spin_lock_irqsave((phyptr-lock), flags);
remove extra parens
+ while (__raw_readl(phyptr-memaddr + MSPPHY_MII_CTRL)
+ MD_CA_BUSY_BIT) {;}
+ __raw_writel(data, phyptr-memaddr + MSPPHY_MII_DATA);
+ __raw_writel(MD_CA_BUSY_BIT | MD_CA_Wr |
+ phyptr-phyaddr 5 | phy_reg,
+ phyptr-memaddr + MSPPHY_MII_CTRL);
+ while (__raw_readl(phyptr-memaddr + MSPPHY_MII_CTRL)
+ MD_CA_BUSY_BIT) {;}
no infinite loops
+ /* unlock */
+ spin_unlock_irqrestore((phyptr-lock), flags);
+}
+
+#ifdef CONFIG_MSPETH_SKB_RECYCLE
+/* initialise the recycle bin for skb */
+static void
+init_skbuff_bin(void)
+{
+ spin_lock_init(skb_bin.lock);
+ skb_bin.recycle_max = RX_BUF_NUM * 4; /* max size of bin */
+ skb_bin.recycle_count = 0;
+ skb_bin.recycle_queue = NULL;
+ skb_bin.user_count = 0;
+}
+
+/* free the skb's in recycle bin */
+static void
+free_skbuff_bin(void)
+{
+ spin_lock_bh(skb_bin.lock);
+
+ /* check any skb's are present in the recycle
[PATCH 3/3] [SCTP] Do not include ABORT chunk header in the notification.
The socket API draft is unclear about whether to include the
chunk header or not. Recent discussion on the sctp implementors
mailing list clarified that the chunk header shouldn't be included,
but the error parameter header still needs to be there.
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
---
net/sctp/ulpevent.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c
index 661ea2d..bfecb35 100644
--- a/net/sctp/ulpevent.c
+++ b/net/sctp/ulpevent.c
@@ -141,11 +141,6 @@ struct sctp_ulpevent *sctp_ulpevent_make_assoc_change(
* an ABORT, so we need to include it in the sac_info.
*/
if (chunk) {
- /* sctp_inqu_pop() has allready pulled off the chunk
-* header. We need to put it back temporarily
-*/
- skb_push(chunk-skb, sizeof(sctp_chunkhdr_t));
-
/* Copy the chunk data to a new skb and reserve enough
* head room to use as notification.
*/
@@ -155,9 +150,6 @@ struct sctp_ulpevent *sctp_ulpevent_make_assoc_change(
if (!skb)
goto fail;
- /* put back the chunk header now that we have a copy */
- skb_pull(chunk-skb, sizeof(sctp_chunkhdr_t));
-
/* Embed the event fields inside the cloned skb. */
event = sctp_skb2event(skb);
sctp_ulpevent_init(event, MSG_NOTIFICATION, skb-truesize);
@@ -168,7 +160,8 @@ struct sctp_ulpevent *sctp_ulpevent_make_assoc_change(
/* Trim the buffer to the right length. */
skb_trim(skb, sizeof(struct sctp_assoc_change) +
-ntohs(chunk-chunk_hdr-length));
+ntohs(chunk-chunk_hdr-length) -
+sizeof(sctp_chunkhdr_t));
} else {
event = sctp_ulpevent_new(sizeof(struct sctp_assoc_change),
MSG_NOTIFICATION, gfp);
--
1.5.0.3.438.gc49b2
-
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 2/3] [SCTP] Correctly copy addresses in sctp_copy_laddrs
I broke the non-wildcard case recently. This is to fixes it.
Now, explictitly bound addresses can ge retrieved using the API.
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
---
net/sctp/socket.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index cc2ed54..ef03bc4 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4164,6 +4164,7 @@ static int sctp_getsockopt_local_addrs_old(struct sock
*sk, int len,
rwlock_t *addr_lock;
int err = 0;
void *addrs;
+ void *buf;
int bytes_copied = 0;
if (len != sizeof(struct sctp_getaddrs_old))
@@ -4217,13 +4218,14 @@ static int sctp_getsockopt_local_addrs_old(struct sock
*sk, int len,
}
}
+ buf = addrs;
list_for_each(pos, bp-address_list) {
addr = list_entry(pos, struct sctp_sockaddr_entry, list);
memcpy(temp, addr-a, sizeof(temp));
sctp_get_pf_specific(sk-sk_family)-addr_v4map(sp, temp);
addrlen = sctp_get_af_specific(temp.sa.sa_family)-sockaddr_len;
- memcpy(addrs, temp, addrlen);
- to += addrlen;
+ memcpy(buf, temp, addrlen);
+ buf += addrlen;
bytes_copied += addrlen;
cnt ++;
if (cnt = getaddrs.addr_num) break;
@@ -4266,6 +4268,7 @@ static int sctp_getsockopt_local_addrs(struct sock *sk,
int len,
size_t space_left;
int bytes_copied = 0;
void *addrs;
+ void *buf;
if (len = sizeof(struct sctp_getaddrs))
return -EINVAL;
@@ -4316,6 +4319,7 @@ static int sctp_getsockopt_local_addrs(struct sock *sk,
int len,
}
}
+ buf = addrs;
list_for_each(pos, bp-address_list) {
addr = list_entry(pos, struct sctp_sockaddr_entry, list);
memcpy(temp, addr-a, sizeof(temp));
@@ -4325,8 +4329,8 @@ static int sctp_getsockopt_local_addrs(struct sock *sk,
int len,
err = -ENOMEM; /*fixme: right error?*/
goto error;
}
- memcpy(addrs, temp, addrlen);
- to += addrlen;
+ memcpy(buf, temp, addrlen);
+ buf += addrlen;
bytes_copied += addrlen;
cnt ++;
space_left -= addrlen;
--
1.5.0.3.438.gc49b2
-
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] [SCTP]: More bugfixes
Hi David This is yet more bugfixes for SCTP: [SCTP] Prevent OOPS if hmac modules didn't load [SCTP] Correctly copy addresses in sctp_copy_laddrs [SCTP] Do not include ABORT chunk header in the notification. Please apply. Thanks -vlad - 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 1/3] [SCTP] Prevent OOPS if hmac modules didn't load
SCTP was checking for NULL when trying to detect hmac
allocation failure where it should have been using IS_ERR.
Also, print a rate limited warning to the log telling the
user what happend.
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
---
net/sctp/socket.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 64fb074..cc2ed54 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -5227,7 +5227,12 @@ int sctp_inet_listen(struct socket *sock, int backlog)
/* Allocate HMAC for generating cookie. */
if (sctp_hmac_alg) {
tfm = crypto_alloc_hash(sctp_hmac_alg, 0, CRYPTO_ALG_ASYNC);
- if (!tfm) {
+ if (IS_ERR(tfm)) {
+ if (net_ratelimit()) {
+ printk(KERN_INFO
+ SCTP: failed to load transform for %s:
%ld\n,
+ sctp_hmac_alg, PTR_ERR(tfm));
+ }
err = -ENOSYS;
goto out;
}
--
1.5.0.3.438.gc49b2
-
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] send ICMPv6 error on scope violations
When an IPv6 router is forwarding a packet with a link-local scope source
address off-link, RFC 4007 requires it to send an ICMPv6 destination
unreachable with code 2 (not neighbor), but Linux doesn't. Fix below.
+-DLS
[in-line for viewing, attached for applying]
Signed-off-by: David L Stevens [EMAIL PROTECTED]
--- linux-2.6.20.7/net/ipv6/ip6_output.c2007-04-13
13:48:14.0 -0700
+++ linux-2.6.20.7T1/net/ipv6/ip6_output.c 2007-05-09
12:32:45.0 -0700
@@ -449,10 +449,17 @@ int ip6_forward(struct sk_buff *skb)
*/
if (xrlim_allow(dst, 1*HZ))
ndisc_send_redirect(skb, n, target);
- } else if
(ipv6_addr_type(hdr-saddr)(IPV6_ADDR_MULTICAST|IPV6_ADDR_LOOPBACK
- |IPV6_ADDR_LINKLOCAL)) {
+ } else {
+ int addrtype = ipv6_addr_type(hdr-saddr);
+
/* This check is security critical. */
- goto error;
+ if (addrtype (IPV6_ADDR_MULTICAST|IPV6_ADDR_LOOPBACK))
+ goto error;
+ if (addrtype IPV6_ADDR_LINKLOCAL) {
+ icmpv6_send(skb, ICMPV6_DEST_UNREACH,
+ ICMPV6_NOT_NEIGHBOUR, 0, skb-dev);
+ goto error;
+ }
}
if (skb-len dst_mtu(dst)) {
icmp6fix.patch
Description: Binary data
Re: [PATCH] vlan: lockdep subclass for ppp _xmit_lock Re: ppp_generic: fix lockdep warning
After applying this patch i've got this:
===
[ INFO: possible circular locking dependency detected ]
2.6.21-gentoo #2
---
ospfd/3984 is trying to acquire lock:
(ppp-wlock){-...}, at: [803512a0] ppp_xmit_process+0x20/0x4f0
but task is already holding lock:
(dev-_xmit_lock){-+..}, at: [8038d778] __qdisc_run+0x88/0x1c3
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #3 (dev-_xmit_lock){-+..}:
[80288f49] __lock_acquire+0xca9/0xf31
[8028921a] lock_acquire+0x49/0x6f
[8038663c] dev_mc_add+0x3c/0x148
[8025e14c] _spin_lock_bh+0x23/0x2c
[8038663c] dev_mc_add+0x3c/0x148
[803bf0fc] vlan_dev_set_multicast_list+0xfc/0x2a0
[80386707] dev_mc_add+0x107/0x148
[803b1406] igmp_group_added+0x44/0x4b
[803b15aa] ip_mc_inc_group+0x12a/0x150
[803b15b2] ip_mc_inc_group+0x132/0x150
[803b160e] ip_mc_up+0x3e/0x5a
[803aeb77] inetdev_event+0x137/0x2d0
[8038b67e] rtmsg_ifinfo+0xae/0xe0
[8027bb24] notifier_call_chain+0x24/0x36
[80384cb6] dev_open+0x66/0x70
[803830c2] dev_change_flags+0x5c/0x12a
[803af5fd] devinet_ioctl+0x2ad/0x6b0
[8037b5e6] sock_ioctl+0x1e6/0x202
[8023eaa1] do_ioctl+0x21/0x79
[8022e5bd] vfs_ioctl+0x28d/0x2b0
[80287dca] trace_hardirqs_on+0x12e/0x164
[80248f89] sys_ioctl+0x3b/0x5b
[8025811e] system_call+0x7e/0x83
[] 0x
- #2 (vlan_netdev_xmit_lock_key){-...}:
[80288f49] __lock_acquire+0xca9/0xf31
[8028921a] lock_acquire+0x49/0x6f
[8022de38] dev_queue_xmit+0x178/0x263
[8025e120] _spin_lock+0x1e/0x27
[8022de38] dev_queue_xmit+0x178/0x263
[80354f57] __pppoe_xmit+0x217/0x23b
[803523e3] ppp_channel_push+0x43/0xb9
[8035331a] ppp_write+0x10a/0x120
[80215895] vfs_write+0xa5/0xf0
[80216238] sys_write+0x45/0x7d
[8025811e] system_call+0x7e/0x83
[] 0x
- #1 (pch-downl){-...}:
[80288f49] __lock_acquire+0xca9/0xf31
[8028921a] lock_acquire+0x49/0x6f
[803509d5] ppp_push+0x45/0xaf
[8025e14c] _spin_lock_bh+0x23/0x2c
[803509d5] ppp_push+0x45/0xaf
[803516e7] ppp_xmit_process+0x467/0x4f0
[80287dca] trace_hardirqs_on+0x12e/0x164
[8035330a] ppp_write+0xfa/0x120
[80215895] vfs_write+0xa5/0xf0
[80216238] sys_write+0x45/0x7d
[8025811e] system_call+0x7e/0x83
[] 0x
- #0 (ppp-wlock){-...}:
[8028483b] print_stack_trace+0x6d/0x8a
[80288e08] __lock_acquire+0xb68/0xf31
[8028921a] lock_acquire+0x49/0x6f
[803512a0] ppp_xmit_process+0x20/0x4f0
[8025e14c] _spin_lock_bh+0x23/0x2c
[803512a0] ppp_xmit_process+0x20/0x4f0
[80287daf] trace_hardirqs_on+0x113/0x164
[803531bc] ppp_start_xmit+0x1dc/0x230
[8038d7f5] __qdisc_run+0x105/0x1c3
[8022dddf] dev_queue_xmit+0x11f/0x263
[80237533] ip_mc_output+0x333/0x370
[803a9460] raw_sendmsg+0x560/0x729
[8025045b] sock_sendmsg+0xcb/0xe3
[80281bbc] autoremove_wake_function+0x0/0x34
[802754bf] local_bh_enable_ip+0xeb/0xfc
[80287dca] trace_hardirqs_on+0x12e/0x164
[8039c20c] ip_setsockopt+0xb1c/0xb3f
[8039c20c] ip_setsockopt+0xb1c/0xb3f
[803813e6] verify_iovec+0x46/0x94
[8037bde0] sys_sendmsg+0x1de/0x249
[8025e3c9] _spin_unlock_irqrestore+0x41/0x4a
[8027bd6f] getrusage+0x19f/0x1ba
[80287dca] trace_hardirqs_on+0x12e/0x164
[8025dbc9] trace_hardirqs_on_thunk+0x35/0x37
[803a8650] raw_setsockopt+0x0/0x54
[8025811e] system_call+0x7e/0x83
[] 0x
other info that might help us debug this:
1 lock held by ospfd/3984:
#0: (dev-_xmit_lock){-+..}, at: [8038d778]
__qdisc_run+0x88/0x1c3
stack backtrace:
Call Trace:
[80286f9d] print_circular_bug_tail+0x6a/0x7d
[8028483b] print_stack_trace+0x6d/0x8a
[80288e08] __lock_acquire+0xb68/0xf31
[8028921a] lock_acquire+0x49/0x6f
[803512a0] ppp_xmit_process+0x20/0x4f0
[8025e14c] _spin_lock_bh+0x23/0x2c
[803512a0] ppp_xmit_process+0x20/0x4f0
[80287daf] trace_hardirqs_on+0x113/0x164
[803531bc] ppp_start_xmit+0x1dc/0x230
Re: [PATCH 1/3] [SCTP] Prevent OOPS if hmac modules didn't load
From: Vlad Yasevich [EMAIL PROTECTED] Date: Wed, 9 May 2007 15:43:48 -0400 SCTP was checking for NULL when trying to detect hmac allocation failure where it should have been using IS_ERR. Also, print a rate limited warning to the log telling the user what happend. Signed-off-by: Vlad Yasevich [EMAIL PROTECTED] Applied, thanks Vlad. - 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 2/3] [SCTP] Correctly copy addresses in sctp_copy_laddrs
From: Vlad Yasevich [EMAIL PROTECTED] Date: Wed, 9 May 2007 15:43:49 -0400 I broke the non-wildcard case recently. This is to fixes it. Now, explictitly bound addresses can ge retrieved using the API. Signed-off-by: Vlad Yasevich [EMAIL PROTECTED] Applied. - 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 3/3] [SCTP] Do not include ABORT chunk header in the notification.
From: Vlad Yasevich [EMAIL PROTECTED] Date: Wed, 9 May 2007 15:43:50 -0400 The socket API draft is unclear about whether to include the chunk header or not. Recent discussion on the sctp implementors mailing list clarified that the chunk header shouldn't be included, but the error parameter header still needs to be there. Signed-off-by: Vlad Yasevich [EMAIL PROTECTED] Applied. - 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: [IPV6] send ICMPv6 error on scope violations
From: David Stevens [EMAIL PROTECTED] Date: Wed, 9 May 2007 13:55:15 -0600 When an IPv6 router is forwarding a packet with a link-local scope source address off-link, RFC 4007 requires it to send an ICMPv6 destination unreachable with code 2 (not neighbor), but Linux doesn't. Fix below. Signed-off-by: David L Stevens [EMAIL PROTECTED] Applied, thanks David. - 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] AF_RXRPC: Reduce debugging noise.
From: David Howells [EMAIL PROTECTED] Date: Wed, 09 May 2007 14:51:47 +0100 Reduce debugging noise generated by AF_RXRPC. Signed-off-by: David Howells [EMAIL PROTECTED] Applied, thanks David. - 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]: Do no rely on skb-dst before it is assigned.
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Wed, 09 May 2007 19:18:35 +0900 (JST) Because skb-dst is assigned in ip6_route_input(), it is really bad to use it in hop-by-hop option handler(s). This fix is also needed for -stable. Closes: Bug #8450 (Eric Sesterhenn [EMAIL PROTECTED]) Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] Applied, thank you. - 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: [IPV6] ROUTE: Assign rt6i_idev for ip6_{prohibit,blk_hole}_entry.
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Wed, 09 May 2007 19:21:21 +0900 (JST) I think this is less critical, but is also suitable for -stable release. Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] Applied, thanks! - 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: linkwatch bustage in git-net
On Wed, 09 May 2007 00:18:14 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: Signed-off-by: Herbert Xu [EMAIL PROTECTED] Thanks for working this out, applied and pushed to net-2.6.git I'm all confused. I just pulled your tree and I see in the log commit 4cba637dbb9a13706494a1c85174c8e736914010 Author: Herbert Xu [EMAIL PROTECTED] Date: Wed May 9 00:17:30 2007 -0700 [NET] link_watch: Always schedule urgent events and commit fe47cdba83b3041e4ac1aa1418431020a4afe1e0 Author: Herbert Xu [EMAIL PROTECTED] Date: Tue May 8 23:22:43 2007 -0700 [NET] link_watch: Eliminate potential delay on wrap-around but in the actual diff and in the checked-out tree I see no sign of the earlier patch (fe47cdba83b3041e4ac1aa1418431020a4afe1e0). I have the old code: /* If we wrap around we'll delay it by at most HZ. */ if (delay HZ) delay = 0; where'd it go? - 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: linkwatch bustage in git-net
From: Andrew Morton [EMAIL PROTECTED] Date: Wed, 9 May 2007 14:11:03 -0700 On Wed, 09 May 2007 00:18:14 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: Signed-off-by: Herbert Xu [EMAIL PROTECTED] Thanks for working this out, applied and pushed to net-2.6.git I'm all confused. I just pulled your tree and I see in the log commit 4cba637dbb9a13706494a1c85174c8e736914010 Author: Herbert Xu [EMAIL PROTECTED] Date: Wed May 9 00:17:30 2007 -0700 [NET] link_watch: Always schedule urgent events and commit fe47cdba83b3041e4ac1aa1418431020a4afe1e0 Author: Herbert Xu [EMAIL PROTECTED] Date: Tue May 8 23:22:43 2007 -0700 [NET] link_watch: Eliminate potential delay on wrap-around but in the actual diff and in the checked-out tree I see no sign of the earlier patch (fe47cdba83b3041e4ac1aa1418431020a4afe1e0). I have the old code: /* If we wrap around we'll delay it by at most HZ. */ if (delay HZ) delay = 0; where'd it go? Look at the two individual changes, Herbert implemented the delay calculations different in the second changeset. So the code is much different there now. - 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 1/1] icom: Add new sub-device-id to support new adapter
This patch add new sub-device-id to support new adapter and changed the
interrupt irq number for unsigned char to unsigned int.
Signed-off by: Wendy Xiong [EMAIL PROTECTED]
diff -Nuar linux-2.6.21-rc7.orig/drivers/serial/icom.c
linux-2.6.21-rc7.new/drivers/serial/icom.c
--- linux-2.6.21-rc7.orig/drivers/serial/icom.c 2008-01-10 23:53:59.0
-0600
+++ linux-2.6.21-rc7.new/drivers/serial/icom.c 2008-01-10 23:58:30.0
-0600
@@ -97,6 +97,13 @@
.subdevice = PCI_DEVICE_ID_IBM_ICOM_FOUR_PORT_MODEL,
.driver_data = ADAPTER_V2,
},
+ {
+ .vendor = PCI_VENDOR_ID_IBM,
+ .device = PCI_DEVICE_ID_IBM_ICOM_DEV_ID_2,
+ .subvendor = PCI_VENDOR_ID_IBM,
+ .subdevice =
PCI_DEVICE_ID_IBM_ICOM_V2_ONE_PORT_RVX_ONE_PORT_MDM_PCIE,
+ .driver_data = ADAPTER_V2,
+},
{}
};
diff -Nuar linux-2.6.21-rc7.orig/drivers/serial/icom.h
linux-2.6.21-rc7.new/drivers/serial/icom.h
--- linux-2.6.21-rc7.orig/drivers/serial/icom.h 2008-01-10 23:53:59.0
-0600
+++ linux-2.6.21-rc7.new/drivers/serial/icom.h 2008-01-10 23:55:42.0
-0600
@@ -258,7 +258,7 @@
struct icom_adapter {
void __iomem * base_addr;
unsigned long base_addr_pci;
- unsigned char irq_number;
+ unsigned int irq_number;
struct pci_dev *pci_dev;
struct icom_port port_info[4];
int index;
diff -Nuar linux-2.6.21-rc7.orig/include/linux/pci_ids.h
linux-2.6.21-rc7.new/include/linux/pci_ids.h
--- linux-2.6.21-rc7.orig/include/linux/pci_ids.h 2008-01-10
23:54:13.0 -0600
+++ linux-2.6.21-rc7.new/include/linux/pci_ids.h2008-01-10
23:59:08.0 -0600
@@ -471,6 +471,7 @@
#define PCI_DEVICE_ID_IBM_ICOM_DEV_ID_20x0219
#define PCI_DEVICE_ID_IBM_ICOM_V2_TWO_PORTS_RVX0x021A
#define PCI_DEVICE_ID_IBM_ICOM_V2_ONE_PORT_RVX_ONE_PORT_MDM0x0251
+#define PCI_DEVICE_ID_IBM_ICOM_V2_ONE_PORT_RVX_ONE_PORT_MDM_PCIE 0x0361
#define PCI_DEVICE_ID_IBM_ICOM_FOUR_PORT_MODEL 0x252
-
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] [IrDA] KingSun/DonShine USB IrDA dongle support
From: Alex Villac�s Lasso [EMAIL PROTECTED] This dongle does not follow the usb-irda specification, so it needs its own special driver. In addition, it uses interrupt endpoints instead of bulk ones as the rest of USB IrDA dongles supported by Linux (just to be different?) and data reads need to be parsed to extract the valid bytes before being unwrapped (details in the comment at the start of the source). No speed commands have been discovered for this dongle, and I suspect it does not have any at all. On plugin, this dongle reports vendor and device IDs: 0x07c0:0x4200 . The Windows driver that is used normally to control this dongle has a filename of DSIR620.SYS . Signed-off-by: Alex Villac�s Lasso [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] --- drivers/net/irda/Kconfig | 14 + drivers/net/irda/Makefile |1 + drivers/net/irda/kingsun-sir.c | 657 3 files changed, 672 insertions(+), 0 deletions(-) create mode 100644 drivers/net/irda/kingsun-sir.c diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig index 7c8ccc0..9d28c75 100644 --- a/drivers/net/irda/Kconfig +++ b/drivers/net/irda/Kconfig @@ -141,6 +141,20 @@ config ACT200L_DONGLE To activate support for ACTiSYS IR-200L dongle you will have to start irattach like this: irattach -d act200l. +config KINGSUN_DONGLE + tristate KingSun/DonShine DS-620 IrDA-USB dongle + depends on IRDA USB EXPERIMENTAL + help + Say Y or M here if you want to build support for the KingSun/DonShine + DS-620 IrDA-USB bridge device driver. + + This USB bridge does not conform to the IrDA-USB device class + specification, and therefore needs its own specific driver. This + dongle supports SIR speed only (9600 bps). + + To compile it as a module, choose M here: the module will be called + kingsun-sir. + comment Old SIR device drivers config IRPORT_SIR diff --git a/drivers/net/irda/Makefile b/drivers/net/irda/Makefile index 5be09f1..233a2f9 100644 --- a/drivers/net/irda/Makefile +++ b/drivers/net/irda/Makefile @@ -45,6 +45,7 @@ obj-$(CONFIG_MCP2120_DONGLE) += mcp2120-sir.o obj-$(CONFIG_ACT200L_DONGLE) += act200l-sir.o obj-$(CONFIG_MA600_DONGLE) += ma600-sir.o obj-$(CONFIG_TOIM3232_DONGLE) += toim3232-sir.o +obj-$(CONFIG_KINGSUN_DONGLE) += kingsun-sir.o # The SIR helper module sir-dev-objs := sir_dev.o sir_dongle.o diff --git a/drivers/net/irda/kingsun-sir.c b/drivers/net/irda/kingsun-sir.c new file mode 100644 index 000..a1eb130 --- /dev/null +++ b/drivers/net/irda/kingsun-sir.c @@ -0,0 +1,657 @@ +/* +* +* Filename: kingsun-sir.c +* Version: 0.1.1 +* Description: Irda KingSun/DonShine USB Dongle +* Status:Experimental +* Author:Alex Villac�s Lasso [EMAIL PROTECTED] +* +* Based on stir4200 and mcs7780 drivers, with (strange?) differences +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2 of the License. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +* +*/ + +/* + * This is my current (2007-04-25) understanding of how this dongle is supposed + * to work. This is based on reverse-engineering and examination of the packet + * data sent and received by the WinXP driver using USBSnoopy. Feel free to + * update here as more of this dongle is known: + * + * General: Unlike the other USB IrDA dongles, this particular dongle exposes, + * not two bulk (in and out) endpoints, but two *interrupt* ones. This dongle, + * like the bulk based ones (stir4200.c and mcs7780.c), requires polling in + * order to receive data. + * Transmission: Just like stir4200, this dongle uses a raw stream of data, + * which needs to be wrapped and escaped in a similar way as in stir4200.c. + * Reception: Poll-based, as in stir4200. Each read returns the contents of a + * 8-byte buffer, of which the first byte (LSB) indicates the number of bytes + * (1-7) of valid data contained within the remaining 7 bytes. For example, if + * the buffer had the following contents: + * 06 ff ff ff c0 01 04 aa + * This means that (06) there are 6 bytes of valid data. The byte 0xaa at the + * end is garbage (left over from a previous reception) and is
Re: Please pull 'upstream' branch of wireless-2.6
John W. Linville wrote: The following changes since commit 5b94f675f57e4ff16c8fda09088d7480a84dcd91: Linus Torvalds (1): Merge master.kernel.org:/.../davem/sparc-2.6 are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream Daniel Drake (1): zd1211rw: Add ID for ZyXEL AG-225H v2 Larry Finger (3): ieee80211: add ieee80211_channel_to_freq ieee80211: include frequency in scan results bcm43xx: Remove dead configuration variable CONFIG_947XX Matthew Davidson (1): zd1211rw: Add ID for Sitecom WL-117 Ulrich Kunitz (1): zd1211rw: Added new USB id for Planex GW-US54ZGL drivers/net/wireless/bcm43xx/bcm43xx.h | 18 +- drivers/net/wireless/bcm43xx/bcm43xx_dma.c |4 - drivers/net/wireless/bcm43xx/bcm43xx_main.c | 81 --- drivers/net/wireless/bcm43xx/bcm43xx_main.h | 19 -- drivers/net/wireless/zd1211rw/zd_usb.c |4 + include/net/ieee80211.h |2 + net/ieee80211/ieee80211_geo.c | 16 + net/ieee80211/ieee80211_wx.c|8 ++- 8 files changed, 31 insertions(+), 121 deletions(-) pulled - 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: Please pull 'upstream-rtl8187' branch of wireless-2.6
John W. Linville wrote:
+static inline void eeprom_93cx6_pulse_high(struct eeprom_93cx6 *eeprom)
+{
+ eeprom-reg_data_clock = 1;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
+
+static inline void eeprom_93cx6_pulse_low(struct eeprom_93cx6 *eeprom)
+{
+ eeprom-reg_data_clock = 0;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
udelay-after-write normally indicates a PCI posting bug (or USB bus
delay bug)
+void eeprom_93cx6_write(struct eeprom_93cx6 *eeprom, const u8 word,
+ u16 data)
+{
+ u16 command;
+
+ /*
+* select the ewen opcode.
+*/
+ eeprom_93cx6_ewen(eeprom);
+
+ /*
+* Initialize the eeprom register
+*/
+ eeprom_93cx6_startup(eeprom);
+
+ /*
+* Select the write opcode and the word to be read.
+*/
+ command = (PCI_EEPROM_WRITE_OPCODE eeprom-width) | word;
+ eeprom_93cx6_write_bits(eeprom, command,
+ PCI_EEPROM_WIDTH_OPCODE + eeprom-width);
+
+ /*
+* Write the requested 16 bits.
+*/
+ eeprom_93cx6_write_bits(eeprom, data, 16);
+
+ /*
+* Cleanup eeprom register.
+*/
+ eeprom_93cx6_cleanup(eeprom);
+
+ /*
+* Take a short break.
+*/
+ msleep(1);
WTF?
First of all, use ssleep()
Second of all, include a non-sarcastic comment that actually describes
the reason for the delay, and why it needs to be so long.
+static inline u8 rtl818x_ioread8(struct rtl8187_priv *priv, u8 *addr)
+{
+ u8 val;
+
+ usb_control_msg(priv-udev, usb_rcvctrlpipe(priv-udev, 0),
+ RTL8187_REQ_GET_REG, RTL8187_REQT_READ,
+ (unsigned long)addr, 0, val, sizeof(val), HZ / 2);
+
+ return val;
+}
+
+static inline u16 rtl818x_ioread16(struct rtl8187_priv *priv, __le16 *addr)
+{
+ __le16 val;
+
+ usb_control_msg(priv-udev, usb_rcvctrlpipe(priv-udev, 0),
+ RTL8187_REQ_GET_REG, RTL8187_REQT_READ,
+ (unsigned long)addr, 0, val, sizeof(val), HZ / 2);
+
+ return le16_to_cpu(val);
+}
+
+static inline u32 rtl818x_ioread32(struct rtl8187_priv *priv, __le32 *addr)
+{
+ __le32 val;
+
+ usb_control_msg(priv-udev, usb_rcvctrlpipe(priv-udev, 0),
+ RTL8187_REQ_GET_REG, RTL8187_REQT_READ,
+ (unsigned long)addr, 0, val, sizeof(val), HZ / 2);
+
+ return le32_to_cpu(val);
+}
Return value should be __le32, etc. Was this driver checked with sparse?
+void rtl8187_write_phy(struct ieee80211_hw *dev, u8 addr, u32 data)
+{
+ struct rtl8187_priv *priv = dev-priv;
+
+ data = 8;
+ data |= addr | 0x80;
+
+ rtl818x_iowrite8(priv, priv-map-PHY[3], (data 24) 0xFF);
+ rtl818x_iowrite8(priv, priv-map-PHY[2], (data 16) 0xFF);
+ rtl818x_iowrite8(priv, priv-map-PHY[1], (data 8) 0xFF);
+ rtl818x_iowrite8(priv, priv-map-PHY[0], data 0xFF);
+
+ mdelay(1);
unexplained delay -- write flush bug?
+static int rtl8187_init_hw(struct ieee80211_hw *dev)
+{
+ struct rtl8187_priv *priv = dev-priv;
+ u8 reg;
+ int i;
+
+ /* reset */
+ rtl818x_iowrite8(priv, priv-map-EEPROM_CMD,
RTL818X_EEPROM_CMD_CONFIG);
+ reg = rtl818x_ioread8(priv, priv-map-CONFIG3);
+ rtl818x_iowrite8(priv, priv-map-CONFIG3, reg |
RTL818X_CONFIG3_ANAPARAM_WRITE);
+ rtl818x_iowrite32(priv, priv-map-ANAPARAM, RTL8225_ANAPARAM_ON);
+ rtl818x_iowrite32(priv, priv-map-ANAPARAM2, RTL8225_ANAPARAM2_ON);
+ rtl818x_iowrite8(priv, priv-map-CONFIG3, reg
~RTL818X_CONFIG3_ANAPARAM_WRITE);
+ rtl818x_iowrite8(priv, priv-map-EEPROM_CMD,
RTL818X_EEPROM_CMD_NORMAL);
+
+ rtl818x_iowrite16(priv, priv-map-INT_MASK, 0);
+
+ mdelay(200);
+ rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x10);
+ rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x11);
+ rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x00);
+ mdelay(200);
ditto
also, kill the magic numbers
+ reg = rtl818x_ioread8(priv, priv-map-CMD);
+ reg = (1 1);
+ reg |= RTL818X_CMD_RESET;
+ rtl818x_iowrite8(priv, priv-map-CMD, reg);
+
+ i = 10;
+ do {
+ mdelay(2);
+ if (!(rtl818x_ioread8(priv, priv-map-CMD)
+ RTL818X_CMD_RESET))
+ break;
+ } while (--i);
+
+ if (!i) {
+ printk(KERN_ERR %s: Reset timeout!\n, wiphy_name(dev-wiphy));
+ return -ETIMEDOUT;
+ }
+
+ /* reload registers from eeprom */
+ rtl818x_iowrite8(priv, priv-map-EEPROM_CMD, RTL818X_EEPROM_CMD_LOAD);
+
+ i = 10;
+ do {
+ mdelay(4);
+ if (!(rtl818x_ioread8(priv, priv-map-EEPROM_CMD)
+ RTL818X_EEPROM_CMD_CONFIG))
+ break;
+ } while (--i);
+
+ if (!i) {
+ printk(KERN_ERR %s:
Re: [PATCH] [IrDA] KingSun/DonShine USB IrDA dongle support
From: Samuel Ortiz [EMAIL PROTECTED] Date: Thu, 10 May 2007 01:40:27 +0300 From: Alex Villac$,3u=(Bs Lasso [EMAIL PROTECTED] This dongle does not follow the usb-irda specification, so it needs its own special driver. In addition, it uses interrupt endpoints instead of bulk ones as the rest of USB IrDA dongles supported by Linux (just to be different?) and data reads need to be parsed to extract the valid bytes before being unwrapped (details in the comment at the start of the source). No speed commands have been discovered for this dongle, and I suspect it does not have any at all. On plugin, this dongle reports vendor and device IDs: 0x07c0:0x4200 . The Windows driver that is used normally to control this dongle has a filename of DSIR620.SYS . Signed-off-by: Alex Villac$,3u=(Bs Lasso [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Applied, thanks a lot. - 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] atl1: add netconsole support
Alexey Dobriyan wrote: Copied from b44 driver, but it works: netconsole: device eth0 not up yet, forcing it atl1: eth0 link is up 100 Mbps full duplex netconsole: network logging started Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- drivers/net/atl1/atl1_main.c | 12 1 file changed, 12 insertions(+) applied - 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] Fix hang on IBM Token Ring PCMCIA card ejection
Paul Walmsley wrote: Ejecting a PCMCIA IBM Token Ring card that has not had its dev-open() called will reliably trigger an uninitialized spinlock oops when spinlock debugging is enabled. The system then hangs, occasionally softlockup oopsing. Apparently ibmtr.c:tok_interrupt() doesn't expect to be called before tok_open(), but tok_interrupt() gets called anyway when the card is ejected. So, set an already-existing flag which causes tok_interrupt() to bail out early upon card ejection. Tested by inserting and removing the PCMCIA card several times. Patch against 2.6.21-rc6. Signed-off-by: Paul Walmsley [EMAIL PROTECTED] --- ibmtr_cs.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) applied - 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 1/2] skge: default WOL should be magic only (rev2)
Stephen Hemminger wrote: By default, the skge driver now enables wake on magic and wake on PHY. This is a bad default (bug), wake on PHY means machine will never shutdown if connected to a switch. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]a --- drivers/net/skge.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- sky2-2.6.21.orig/drivers/net/skge.c 2007-05-08 10:06:39.0 -0700 +++ sky2-2.6.21/drivers/net/skge.c 2007-05-08 10:21:51.0 -0700 @@ -3594,7 +3594,9 @@ static struct net_device *skge_devinit(s skge-duplex = -1; skge-speed = -1; skge-advertising = skge_supported_modes(hw); - skge-wol = pci_wake_enabled(hw-pdev) ? wol_supported(hw) : 0; + + if (pci_wake_enabled(hw-pdev)) + skge-wol = wol_supported(hw) WAKE_MAGIC; thanks for the revision, applied - 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 00/17] sky2 update for 2.6.22
Stephen Hemminger wrote: On Wed, 09 May 2007 00:16:48 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: Patches are against netdev-2.6 upstream code branch. This includes a several bug fixes, and code cleanup to use standard functions. There are a couple of PCI changes. One bug fix, and moving common code in PCI base. The standard development process is: * new code gets pushed to me during 2.6.X-rc * that code is auto-propagated to akpm's -mm tree for additional exposure * merge window opens * I push upstream That ensures code gets at least /some/ additional review, testing, settling time. Sorry for the late merge, but between the closing of OSDL office and the fixing of critical bugs the other stuff got pushed into the next release bin and wasn't really ready until now. This is a late date to be expecting stuff to be pushed straight into 2.6.22. Then hold it for 2.6.23. You sure you don't want to split off the bug fixes, and submit those for 2.6.22? An oops fix is certainly 2.6.22 material... Additionally, the rule for creating patches is: diff against latest vanilla linux-2.6.git tree, unless dependencies exist in netdev. After the merge window opens, #upstream is often empty or even a bit behind upstream, since Linus pulls that. One patch wouldn't have applied unless the recent patch that you accepted was included. OK, I stand corrected on this issue, then. It sounds like you diff'd correctly. Jeff - 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 2/6] phylib: add the ICPlus IP175C PHY driver
Kim Phillips wrote:
+ /* master reset */
+ err = phydev-bus-write(phydev-bus, 30, 0, 0x175c);
+ if (err 0)
+ return err;
+
+ /* data sheet specifies reset period is 2 msec */
+ udelay(3000);
+
+ /* enable IP175C mode */
+ err = phydev-bus-write(phydev-bus, 29, 31, 0x175c);
+ if (err 0)
+ return err;
1) use mdelay()
2) write-followed-by-delay does not guarantee the delay, because you
have not factored in PCI posting (or other bus delays)
+ /* Set MII0 speed and duplex (in PHY mode) */
+ err = phydev-bus-write(phydev-bus, 29, 22, 0x420);
+ if (err 0)
+ return err;
+
+ for (i=0; i5; i++) {
+ err = phydev-bus-write(phydev-bus, i, MII_BMCR,
BMCR_RESET);
+ }
+ udelay(3000);
ditto
+ full_reset_performed = 1;
+ }
+
+ if (phydev-addr != 4) {
+ phydev-state = PHY_RUNNING;
+ phydev-speed = SPEED_100;
+ phydev-duplex = DUPLEX_FULL;
+ phydev-link = 1;
+ netif_carrier_on(phydev-attached_dev);
+ }
+
+ return 0;
+}
+
+static int ip175c_read_status(struct phy_device *phydev)
+{
+ if (phydev-addr == 4) { /* if WAN port */
+ genphy_read_status(phydev);
+ } else {
+ /* Don't need to read status for switch ports */
+ phydev-irq = PHY_IGNORE_INTERRUPT;
+ }
+
+ return 0;
+}
+
+
+static int ip175c_config_aneg(struct phy_device *phydev)
+{
+ if (phydev-addr == 4) { /* if WAN port */
+ genphy_config_aneg(phydev);
+ }
codingstyle: remove braces around single C statements
-
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 0/6] RESEND of missed ucc_geth phylib and SGMII patches
hmmm, I received #0 and #2-#6, but not patch #1 - 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 3/6] phylib: enable RGMII-ID on the Marvell m88e1111 PHY
Kim Phillips wrote: Support for configuring RGMII-ID (RGMII with internal delay) mode on the 88e and 88e1145. Also renamed 88es - 88e (no references to an 88es part were found), and fixed some whitespace. Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- drivers/net/phy/marvell.c | 62 +++-- 1 files changed, 54 insertions(+), 8 deletions(-) ACK 3-6 - 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: SG_IO with 4k buffer size to iscsi sg device causes Bad page panic
Qi, Yanling [EMAIL PROTECTED] wrote:
@@ -2571,6 +2572,13 @@ sg_page_malloc(int rqSz, int lowDma, int
resp = (char *) __get_free_pages(page_mask, order);
/* try half */
resSz = a_size;
}
+ tmppage = virt_to_page(resp);
+ for( m = PAGE_SIZE; m resSz; m += PAGE_SIZE )
+ {
+ tmppage++;
+ SetPageReserved(tmppage);
+ }
+
Why not just increase the page use count?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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 3/3] AFS: Implement basic file write support
David Howells wrote:
+/*
+ * prepare a page for being written to
+ */
+static int afs_prepare_page(struct afs_vnode *vnode, struct page *page,
+ struct key *key, unsigned offset, unsigned to)
+{
+ unsigned eof, tail, start, stop, len;
+ loff_t i_size, pos;
+ void *p;
+ int ret;
+
+ _enter();
+
+ if (offset == 0 to == PAGE_SIZE)
+ return 0;
+
+ p = kmap(page);
+
+ i_size = i_size_read(vnode-vfs_inode);
+ pos = (loff_t) page-index PAGE_SHIFT;
+ if (pos = i_size) {
+ /* partial write, page beyond EOF */
+ _debug(beyond);
+ if (offset 0)
+ memset(p, 0, offset);
+ if (to PAGE_SIZE)
+ memset(p + to, 0, PAGE_SIZE - to);
+ kunmap(page);
+ return 0;
+ }
+
+ if (i_size - pos = PAGE_SIZE) {
+ /* partial write, page entirely before EOF */
+ _debug(before);
+ tail = eof = PAGE_SIZE;
+ } else {
+ /* partial write, page overlaps EOF */
+ eof = i_size - pos;
+ _debug(overlap %u, eof);
+ tail = max(eof, to);
+ if (tail PAGE_SIZE)
+ memset(p + tail, 0, PAGE_SIZE - tail);
+ if (offset eof)
+ memset(p + eof, 0, PAGE_SIZE - eof);
+ }
+
+ kunmap(p);
+
+ ret = 0;
+ if (offset 0 || eof to) {
+ /* need to fill one or two bits that aren't going to be written
+* (cover both fillers in one read if there are two) */
+ start = (offset 0) ? 0 : to;
+ stop = (eof to) ? eof : offset;
+ len = stop - start;
+ _debug(wr=%u-%u av=0-%u [EMAIL PROTECTED],
+ offset, to, eof, start, len);
+ ret = afs_fill_page(vnode, key, start, len, page);
+ }
+
+ _leave( = %d, ret);
+ return ret;
+}
+
+/*
+ * prepare to perform part of a write to a page
+ * - the caller holds the page locked, preventing it from being written out or
+ * modified by anyone else
+ */
+int afs_prepare_write(struct file *file, struct page *page,
+ unsigned offset, unsigned to)
+{
+ struct afs_writeback *candidate, *wb;
+ struct afs_vnode *vnode = AFS_FS_I(file-f_dentry-d_inode);
+ struct key *key = file-private_data;
+ pgoff_t index;
+ int ret;
+
+ _enter({%x:%u},{%lx},%u,%u,
+ vnode-fid.vid, vnode-fid.vnode, page-index, offset, to);
+
+ candidate = kzalloc(sizeof(*candidate), GFP_KERNEL);
+ if (!candidate)
+ return -ENOMEM;
+ candidate-vnode = vnode;
+ candidate-first = candidate-last = page-index;
+ candidate-offset_first = offset;
+ candidate-to_last = to;
+ candidate-usage = 1;
+ candidate-state = AFS_WBACK_PENDING;
+ init_waitqueue_head(candidate-waitq);
+
+ if (!PageUptodate(page)) {
+ _debug(not up to date);
+ ret = afs_prepare_page(vnode, page, key, offset, to);
+ if (ret 0) {
+ kfree(candidate);
+ _leave( = %d [prep], ret);
+ return ret;
+ }
+ SetPageUptodate(page);
+ }
Why do you call SetPageUptodate when the page is not up to date?
That leaks uninitialised data, AFAIKS.
--
SUSE Labs, Novell Inc.
-
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
[git patches] few more net driver updates, fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/atl1/atl1_main.c| 12
drivers/net/pcmcia/ibmtr_cs.c | 14 +++--
drivers/net/skge.c |4 +-
drivers/net/wireless/bcm43xx/bcm43xx.h | 18 +-
drivers/net/wireless/bcm43xx/bcm43xx_dma.c |4 -
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 81 ---
drivers/net/wireless/bcm43xx/bcm43xx_main.h | 19 --
drivers/net/wireless/zd1211rw/zd_usb.c |4 +
include/net/ieee80211.h |2 +
net/ieee80211/ieee80211_geo.c | 16 +
net/ieee80211/ieee80211_wx.c|8 ++-
11 files changed, 55 insertions(+), 127 deletions(-)
Alexey Dobriyan (1):
atl1: add netconsole support
Daniel Drake (1):
zd1211rw: Add ID for ZyXEL AG-225H v2
Larry Finger (3):
ieee80211: add ieee80211_channel_to_freq
ieee80211: include frequency in scan results
bcm43xx: Remove dead configuration variable CONFIG_947XX
Matthew Davidson (1):
zd1211rw: Add ID for Sitecom WL-117
Paul Walmsley (1):
Fix hang on IBM Token Ring PCMCIA card ejection
Stephen Hemminger (1):
skge: default WOL should be magic only (rev2)
Ulrich Kunitz (1):
zd1211rw: Added new USB id for Planex GW-US54ZGL
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index d28f88b..78cf00f 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -2038,6 +2038,15 @@ static int atl1_close(struct net_device *netdev)
return 0;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void atl1_poll_controller(struct net_device *netdev)
+{
+ disable_irq(netdev-irq);
+ atl1_intr(netdev-irq, netdev);
+ enable_irq(netdev-irq);
+}
+#endif
+
/*
* If TPD Buffer size equal to 0, PCIE DMAR_TO_INT
* will assert. We do soft reset 0x1400=1 according
@@ -2190,6 +2199,9 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
netdev-do_ioctl = atl1_ioctl;
netdev-tx_timeout = atl1_tx_timeout;
netdev-watchdog_timeo = 5 * HZ;
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ netdev-poll_controller = atl1_poll_controller;
+#endif
netdev-vlan_rx_register = atl1_vlan_rx_register;
netdev-vlan_rx_add_vid = atl1_vlan_rx_add_vid;
netdev-vlan_rx_kill_vid = atl1_vlan_rx_kill_vid;
diff --git a/drivers/net/pcmcia/ibmtr_cs.c b/drivers/net/pcmcia/ibmtr_cs.c
index 1060154..4ecb8ca 100644
--- a/drivers/net/pcmcia/ibmtr_cs.c
+++ b/drivers/net/pcmcia/ibmtr_cs.c
@@ -189,16 +189,20 @@ static void ibmtr_detach(struct pcmcia_device *link)
{
struct ibmtr_dev_t *info = link-priv;
struct net_device *dev = info-dev;
+ struct tok_info *ti = netdev_priv(dev);
DEBUG(0, ibmtr_detach(0x%p)\n, link);
+
+/*
+ * When the card removal interrupt hits tok_interrupt(),
+ * bail out early, so we don't crash the machine
+ */
+ti-sram_phys |= 1;
if (link-dev_node)
unregister_netdev(dev);
-
-{
- struct tok_info *ti = netdev_priv(dev);
- del_timer_sync((ti-tr_timer));
-}
+
+del_timer_sync((ti-tr_timer));
ibmtr_release(link);
diff --git a/drivers/net/skge.c b/drivers/net/skge.c
index b07da10..e048957 100644
--- a/drivers/net/skge.c
+++ b/drivers/net/skge.c
@@ -3594,7 +3594,9 @@ static struct net_device *skge_devinit(struct skge_hw
*hw, int port,
skge-duplex = -1;
skge-speed = -1;
skge-advertising = skge_supported_modes(hw);
- skge-wol = pci_wake_enabled(hw-pdev) ? wol_supported(hw) : 0;
+
+ if (pci_wake_enabled(hw-pdev))
+ skge-wol = wol_supported(hw) WAKE_MAGIC;
hw-dev[port] = dev;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx.h
b/drivers/net/wireless/bcm43xx/bcm43xx.h
index f8483c1..10e07e8 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -658,12 +658,6 @@ struct bcm43xx_pio {
#define BCM43xx_MAX_80211_CORES2
-#ifdef CONFIG_BCM947XX
-#define core_offset(bcm) (bcm)-current_core_offset
-#else
-#define core_offset(bcm) 0
-#endif
-
/* Generic information about a core. */
struct bcm43xx_coreinfo {
u8 available:1,
@@ -789,10 +783,6 @@ struct bcm43xx_private {
/* The currently active core. */
struct bcm43xx_coreinfo *current_core;
-#ifdef CONFIG_BCM947XX
- /** current core memory offset */
- u32 current_core_offset;
-#endif
struct bcm43xx_coreinfo *active_80211_core;
/* coreinfo structs for all possible cores follow.
* Note that a core might not exist.
@@ -943,25 +933,25 @@ struct bcm43xx_lopair * bcm43xx_get_lopair(struct
bcm43xx_phyinfo *phy,
static inline
u16 bcm43xx_read16(struct bcm43xx_private *bcm, u16 offset)
{
- return
[PATCH]: Fix up AF-specific references in UDP
As noticed we make some ipv4-specific references in the generic
UDP code, I've fixed that up completely below.
This should fix ipv6 and it should be fully functional.
There is enough infrastructure there to write up the
non-wildcard IPV6 hashing support. Eric and Yoshifuji
had some ideas about how to hash the rcv_saddr so I
will leave those bits to them :-)
It is very easy, just add the appropriate hashing to
ipv6_hash_port_and_rcv_addr(), then add the lookup logic
to the ipv6 UDP socket demux for unicast and multicast
to match the ipv4 equivalent code.
Meanwhile I'll push this patch below to Linus so that
IPV6 isn't broken.
commit 30959ab670629ac857d04c7bc87df422fc941ec9
Author: David S. Miller [EMAIL PROTECTED]
Date: Wed May 9 16:42:20 2007 -0700
[UDP]: Fix AF-specific references in AF-agnostic code.
__udp_lib_port_inuse() cannot make direct references to
inet_sk(sk)-rcv_saddr as that is ipv4 specific state and
this code is used by ipv6 too.
Use an operations vector to solve this, and this also paves
the way for ipv6 support for non-wild saddr hashing in UDP.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/include/net/udp.h b/include/net/udp.h
index 98755eb..496f89d 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -119,9 +119,16 @@ static inline void udp_lib_close(struct sock *sk, long
timeout)
}
+struct udp_get_port_ops {
+ int (*saddr_cmp)(const struct sock *sk1, const struct sock *sk2);
+ int (*saddr_any)(const struct sock *sk);
+ unsigned int (*hash_port_and_rcv_saddr)(__u16 port,
+ const struct sock *sk);
+};
+
/* net/ipv4/udp.c */
extern int udp_get_port(struct sock *sk, unsigned short snum,
-int (*saddr_cmp)(const struct sock *, const struct
sock *));
+const struct udp_get_port_ops *ops);
extern voidudp_err(struct sk_buff *, u32);
extern int udp_sendmsg(struct kiocb *iocb, struct sock *sk,
diff --git a/include/net/udplite.h b/include/net/udplite.h
index 635b0ea..50b4b42 100644
--- a/include/net/udplite.h
+++ b/include/net/udplite.h
@@ -120,5 +120,5 @@ static inline __wsum udplite_csum_outgoing(struct sock *sk,
struct sk_buff *skb)
extern voidudplite4_register(void);
extern int udplite_get_port(struct sock *sk, unsigned short snum,
- int (*scmp)(const struct sock *, const struct sock *));
+const struct udp_get_port_ops *ops);
#endif /* _UDPLITE_H */
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 113e0c4..f7c3b25 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -118,15 +118,15 @@ static int udp_port_rover;
* Note about this hash function :
* Typical use is probably daddr = 0, only dport is going to vary hash
*/
-static inline unsigned int hash_port_and_addr(__u16 port, __be32 addr)
+static inline unsigned int udp_hash_port(__u16 port)
{
- addr ^= addr 16;
- addr ^= addr 8;
- return port ^ addr;
+ return port;
}
static inline int __udp_lib_port_inuse(unsigned int hash, int port,
- __be32 daddr, struct hlist_head udptable[])
+ const struct sock *this_sk,
+ struct hlist_head udptable[],
+ const struct udp_get_port_ops *ops)
{
struct sock *sk;
struct hlist_node *node;
@@ -138,7 +138,10 @@ static inline int __udp_lib_port_inuse(unsigned int hash,
int port,
inet = inet_sk(sk);
if (inet-num != port)
continue;
- if (inet-rcv_saddr == daddr)
+ if (this_sk) {
+ if (ops-saddr_cmp(sk, this_sk))
+ return 1;
+ } else if (ops-saddr_any(sk))
return 1;
}
return 0;
@@ -151,12 +154,11 @@ static inline int __udp_lib_port_inuse(unsigned int hash,
int port,
* @snum:port number to look up
* @udptable:hash list table, must be of UDP_HTABLE_SIZE
* @port_rover: pointer to record of last unallocated port
- * @saddr_comp: AF-dependent comparison of bound local IP addresses
+ * @ops: AF-dependent address operations
*/
int __udp_lib_get_port(struct sock *sk, unsigned short snum,
struct hlist_head udptable[], int *port_rover,
- int (*saddr_comp)(const struct sock *sk1,
-const struct sock *sk2 ))
+ const struct udp_get_port_ops *ops)
{
struct hlist_node *node;
struct hlist_head *head;
@@ -176,8 +178,7 @@ int __udp_lib_get_port(struct sock *sk, unsigned short snum,
for (i = 0; i UDP_HTABLE_SIZE; i++, result++) {
int size;
- hash = hash_port_and_addr(result,
-
Re: Please pull 'upstream-rtl8187' branch of wireless-2.6
On Wednesday 09 May 2007 19:12, Jeff Garzik wrote:
John W. Linville wrote:
+static inline void eeprom_93cx6_pulse_high(struct eeprom_93cx6 *eeprom)
+{
+ eeprom-reg_data_clock = 1;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
+
+static inline void eeprom_93cx6_pulse_low(struct eeprom_93cx6 *eeprom)
+{
+ eeprom-reg_data_clock = 0;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
udelay-after-write normally indicates a PCI posting bug (or USB bus
delay bug)
Things may go bad if we try to bitbang the eeprom too fast.
+void eeprom_93cx6_write(struct eeprom_93cx6 *eeprom, const u8 word,
+ u16 data)
+{
+ u16 command;
+
+ /*
+* select the ewen opcode.
+*/
+ eeprom_93cx6_ewen(eeprom);
+
+ /*
+* Initialize the eeprom register
+*/
+ eeprom_93cx6_startup(eeprom);
+
+ /*
+* Select the write opcode and the word to be read.
+*/
+ command = (PCI_EEPROM_WRITE_OPCODE eeprom-width) | word;
+ eeprom_93cx6_write_bits(eeprom, command,
+ PCI_EEPROM_WIDTH_OPCODE + eeprom-width);
+
+ /*
+* Write the requested 16 bits.
+*/
+ eeprom_93cx6_write_bits(eeprom, data, 16);
+
+ /*
+* Cleanup eeprom register.
+*/
+ eeprom_93cx6_cleanup(eeprom);
+
+ /*
+* Take a short break.
+*/
+ msleep(1);
WTF?
First of all, use ssleep()
Second of all, include a non-sarcastic comment that actually describes
the reason for the delay, and why it needs to be so long.
This function can be dropped entirely. (no driver bothers to write to the
eeprom yet)
+static inline u8 rtl818x_ioread8(struct rtl8187_priv *priv, u8 *addr)
+{
+ u8 val;
+
+ usb_control_msg(priv-udev, usb_rcvctrlpipe(priv-udev, 0),
+ RTL8187_REQ_GET_REG, RTL8187_REQT_READ,
+ (unsigned long)addr, 0, val, sizeof(val), HZ / 2);
+
+ return val;
+}
+
+static inline u16 rtl818x_ioread16(struct rtl8187_priv *priv, __le16
*addr) +{
+ __le16 val;
+
+ usb_control_msg(priv-udev, usb_rcvctrlpipe(priv-udev, 0),
+ RTL8187_REQ_GET_REG, RTL8187_REQT_READ,
+ (unsigned long)addr, 0, val, sizeof(val), HZ / 2);
+
+ return le16_to_cpu(val);
+}
+
+static inline u32 rtl818x_ioread32(struct rtl8187_priv *priv, __le32
*addr) +{
+ __le32 val;
+
+ usb_control_msg(priv-udev, usb_rcvctrlpipe(priv-udev, 0),
+ RTL8187_REQ_GET_REG, RTL8187_REQT_READ,
+ (unsigned long)addr, 0, val, sizeof(val), HZ / 2);
+
+ return le32_to_cpu(val);
+}
Return value should be __le32, etc. Was this driver checked with sparse?
Yes, fully checked with sparse. No, it should not be __le32 because this keeps
the behavior of the rtl8187 ioread consistent with the behavior of the PCI
ioread/iowrite functions which byteswap everything to native order.
+void rtl8187_write_phy(struct ieee80211_hw *dev, u8 addr, u32 data)
+{
+ struct rtl8187_priv *priv = dev-priv;
+
+ data = 8;
+ data |= addr | 0x80;
+
+ rtl818x_iowrite8(priv, priv-map-PHY[3], (data 24) 0xFF);
+ rtl818x_iowrite8(priv, priv-map-PHY[2], (data 16) 0xFF);
+ rtl818x_iowrite8(priv, priv-map-PHY[1], (data 8) 0xFF);
+ rtl818x_iowrite8(priv, priv-map-PHY[0], data 0xFF);
+
+ mdelay(1);
unexplained delay -- write flush bug?
Most likely to just keep the hardware from choking or give the radio chip some
time to receive the information.
+static int rtl8187_init_hw(struct ieee80211_hw *dev)
+{
+ struct rtl8187_priv *priv = dev-priv;
+ u8 reg;
+ int i;
+
+ /* reset */
+ rtl818x_iowrite8(priv, priv-map-EEPROM_CMD,
RTL818X_EEPROM_CMD_CONFIG); + reg = rtl818x_ioread8(priv,
priv-map-CONFIG3);
+ rtl818x_iowrite8(priv, priv-map-CONFIG3, reg |
RTL818X_CONFIG3_ANAPARAM_WRITE); + rtl818x_iowrite32(priv,
priv-map-ANAPARAM, RTL8225_ANAPARAM_ON); + rtl818x_iowrite32(priv,
priv-map-ANAPARAM2, RTL8225_ANAPARAM2_ON); + rtl818x_iowrite8(priv,
priv-map-CONFIG3, reg ~RTL818X_CONFIG3_ANAPARAM_WRITE);
+ rtl818x_iowrite8(priv, priv-map-EEPROM_CMD,
RTL818X_EEPROM_CMD_NORMAL); +
+ rtl818x_iowrite16(priv, priv-map-INT_MASK, 0);
+
+ mdelay(200);
+ rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x10);
+ rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x11);
+ rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x00);
+ mdelay(200);
ditto
also, kill the magic numbers
I have no idea what that does so I don't see the point in moving the number to
some define. However, the hardware does seem to work okay without this part
so I can remove it if you bothers you so much.
+ reg = rtl818x_ioread8(priv, priv-map-CMD);
+ reg = (1 1);
+ reg |= RTL818X_CMD_RESET;
+ rtl818x_iowrite8(priv, priv-map-CMD, reg);
+
+ i = 10;
+ do {
+ mdelay(2);
+ if
[BUG][debian-2.6.20-1-686] bridging + vlans + vconfig rem == stuck kernel
I've managed to fairly reliably trigger a deadlock in some portion of
the linux networking code on my Debian test box (using the debian
kernel linux-image-2.6.20-1-686). I'm pretty sure that it's a race
condition of some sort as it doesn't trigger if I ifdown the
interfaces one by one, but if I run ifdown -a then it triggers
halfway through reliably (although not with the same reference count
numbers, once it was 6, this time it was 2).
The message I get is: unregister_netdevice: waiting for world0 to
become free. Usage count = 2
My /etc/network/interfaces file uses a couple custom-made if-pre-up.d
and if-post-down.d scripts to set up the bridges and VLANs a little
more cleanly than the standard debian scripts do, but the general
configuration is as follows:
net0: Tigon-3 onboard gigabit NIC, hooked to managed switch, untagged
packets
wfi0: (net0.2 before renaming) WAP-connected VLAN 2 on the managed
switch
world0: (net0.4094 before renaming) Internet connection, runs DHCP
lan: Local Area Network bridge of net0 and wfi0 (current box has
lowest STP priority) This will eventually also have another untagged-
only ethernet port attached to it.
lan:0: Alias for acting as primary nameserver
world: pseudo-bridge of world0 for highly-available DHCP client.
Just for a bit of background on why this is so complex: When I get
this networking problem sorted out I'm going to set up heartbeat and
a dummy world1 interface with a shared MAC which is added to the
world bridge when the current system is the DHCP-client master.
Hopefully that way I can have 3 systems act as a highly-available
router. Whichever one is currently the master will add the dummy
world1 interface with shared MAC address to its world bridge and
bring dhcp3-client up on the world1 interface with the latest copy
of the leases file from the previous master (even if the previous
master mysteriously crashed. This should keep my public IP from
changing unnecessarily and should allow me to reboot any one of the 3
router/firewall/mailserver/fileserver/etc systems without adversely
affecting the internet connection or other critical services.
Eventually I plan to add ebtables to help filter traffic between wfi*
interfaces and untagged VLAN-1 net* interfaces, but for now there's
no filtering.
Anyways, after the unregister_netdevice messages start popping up all
sorts of networking related things start to hang hard in the kernel;
I can't ip link set down any interfaces, etc. I've captured sysrq
dumps of the process state on the system at the time with most
processes. See the attached syslog.bz2 file.
The important part is probably the stuck vconfig process, but I
don't really understand enough about the timer stuff to interpret
that backtrace.
vconfig D 83CCD8CE 0 16564 16562 (NOTLB)
efdd7e7c 0086 ee120afb 83ccd8ce 98f00788 b7083ffa
5384b49a c76c0b05
9ebaf791 0004 efdd7e4e 0007 f1468a90 2ab74174
0362 0326
f1468b9c c180e420 0001 0286 c012933c efdd7e8c
df98a000 c180e468
Call Trace:
[c012933c] lock_timer_base+0x15/0x2f
[c0129445] __mod_timer+0x91/0x9b
[c02988f5] schedule_timeout+0x70/0x8d
[f8b75209] vlan_device_event+0x13/0xf8 [8021q]
[c0128bfe] process_timeout+0x0/0x5
[c01295db] msleep+0x1a/0x1f
[c023e5a9] netdev_run_todo+0x10f/0x203
[f8b757d4] vlan_ioctl_handler+0x4dc/0x594 [8021q]
[c023398d] sock_ioctl+0x145/0x1be
[c0233848] sock_ioctl+0x0/0x1be
[c016c39f] do_ioctl+0x1f/0x62
[c016c626] vfs_ioctl+0x244/0x256
[c016c684] sys_ioctl+0x4c/0x64
[c0102d70] syscall_call+0x7/0xb
There's also a whole bunch of processes stuck in netdev_run_todo()
trying to lock a mutex. This even frustratingly affects things like
rndc which use netlink sockets:
rpc.mountdD C9F2BD14 0 4351 1 4425 4229 (NOTLB)
c9f2bd28 0086 0002 c9f2bd14 c9f2bd10
10ff 46422e36
0002 0202 0007 ed266030 495bcd12
03a5 00013461
ed26613c c180e420 0001 dffc8200 dfaeb580
10ff df99ce00
Call Trace:
[c0298c09] __mutex_lock_slowpath+0x48/0x77
[c0298ac0] mutex_lock+0xa/0xb
[c023e4aa] netdev_run_todo+0x10/0x203
[c0251460] netlink_run_queue+0x9f/0xbe
[c0243ac9] rtnetlink_rcv_msg+0x0/0x1d9
[c0243a97] rtnetlink_rcv+0x34/0x3d
[c0251880] netlink_data_ready+0x12/0x4c
[c0250841] netlink_sendskb+0x19/0x30
[c0251862] netlink_sendmsg+0x26a/0x276
[c02341b9] sock_sendmsg+0xd0/0xeb
[c0131e95] autoremove_wake_function+0x0/0x35
[c020a2be] extract_entropy+0x45/0x89
[c011a485] __wake_up+0x32/0x43
[c0250aa6] netlink_insert+0x10f/0x119
[c02344e3] sys_sendto+0x116/0x140
[c014841a] find_get_page+0x18/0x41
[c014a736] filemap_nopage+0x197/0x2f9
[c0234ea9] sys_getsockname+0x86/0xb0
[c015341a] __handle_mm_fault+0x2ee/0x7d4
[c0235207] sys_socketcall+0x15e/0x242
[c0102d70] syscall_call+0x7/0xb
The zz-km-vlan script is the bash if-post-down.d
RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior
On Tue, 2007-05-08 at 19:28 -0400, jamal wrote: Wireless with CSMA/CA is a slightly different beast due to the shared channels; its worse but not very different in nature than the case where you have a shared ethernet hub (CSMA/CD) and you keep adding hosts to it The difference is the hub provides the same transmission chance for all the packets but in wireless, high priority packets will block low priority packets transmission. You can argue there is still chances a low priority packet is sent first before a high priority one. But this is not the point of wireless QoS. It rarely happens and should be avoid at best effort in the implementation. Thanks, -yi - 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: Please pull 'upstream-rtl8187' branch of wireless-2.6
Michael Wu wrote:
On Wednesday 09 May 2007 19:12, Jeff Garzik wrote:
John W. Linville wrote:
+static inline void eeprom_93cx6_pulse_high(struct eeprom_93cx6 *eeprom)
+{
+ eeprom-reg_data_clock = 1;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
+
+static inline void eeprom_93cx6_pulse_low(struct eeprom_93cx6 *eeprom)
+{
+ eeprom-reg_data_clock = 0;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
udelay-after-write normally indicates a PCI posting bug (or USB bus
delay bug)
Things may go bad if we try to bitbang the eeprom too fast.
You are misunderstanding the point here.
I was not asking why you needed the delay. I was making an assertion
about the unreliable nature of such delays.
Sending a register write to a device is vastly different from knowing
that the write has been received and processed by the device.
On a PCI bus, this is called PCI write posting, where writes can be
delayed and/or combined with other writes. There is a similar concept
with USB, because you are dealing with packets going to and from a USB
device.
You fundamentally cannot assume that the write has arrived at the device
by the time the CPU is executing the next C statement (udelay) on the host.
The normal procedure for PCI is to issue a read, which thereby
guarantees that any writes have been flushed to the device. I presume
the same technique works with USB, but do not know for certain.
+static inline u8 rtl818x_ioread8(struct rtl8187_priv *priv, u8 *addr)
+{
+ u8 val;
+
+ usb_control_msg(priv-udev, usb_rcvctrlpipe(priv-udev, 0),
+ RTL8187_REQ_GET_REG, RTL8187_REQT_READ,
+ (unsigned long)addr, 0, val, sizeof(val), HZ / 2);
+
+ return val;
+}
+
+static inline u16 rtl818x_ioread16(struct rtl8187_priv *priv, __le16
*addr) +{
+ __le16 val;
+
+ usb_control_msg(priv-udev, usb_rcvctrlpipe(priv-udev, 0),
+ RTL8187_REQ_GET_REG, RTL8187_REQT_READ,
+ (unsigned long)addr, 0, val, sizeof(val), HZ / 2);
+
+ return le16_to_cpu(val);
+}
+
+static inline u32 rtl818x_ioread32(struct rtl8187_priv *priv, __le32
*addr) +{
+ __le32 val;
+
+ usb_control_msg(priv-udev, usb_rcvctrlpipe(priv-udev, 0),
+ RTL8187_REQ_GET_REG, RTL8187_REQT_READ,
+ (unsigned long)addr, 0, val, sizeof(val), HZ / 2);
+
+ return le32_to_cpu(val);
+}
Return value should be __le32, etc. Was this driver checked with sparse?
Yes, fully checked with sparse. No, it should not be __le32 because this keeps
Yes, you're right. I misread the code.
+void rtl8187_write_phy(struct ieee80211_hw *dev, u8 addr, u32 data)
+{
+ struct rtl8187_priv *priv = dev-priv;
+
+ data = 8;
+ data |= addr | 0x80;
+
+ rtl818x_iowrite8(priv, priv-map-PHY[3], (data 24) 0xFF);
+ rtl818x_iowrite8(priv, priv-map-PHY[2], (data 16) 0xFF);
+ rtl818x_iowrite8(priv, priv-map-PHY[1], (data 8) 0xFF);
+ rtl818x_iowrite8(priv, priv-map-PHY[0], data 0xFF);
+
+ mdelay(1);
unexplained delay -- write flush bug?
Most likely to just keep the hardware from choking or give the radio chip some
time to receive the information.
See above and reevaluate.
+static int rtl8187_init_hw(struct ieee80211_hw *dev)
+{
+ struct rtl8187_priv *priv = dev-priv;
+ u8 reg;
+ int i;
+
+ /* reset */
+ rtl818x_iowrite8(priv, priv-map-EEPROM_CMD,
RTL818X_EEPROM_CMD_CONFIG); + reg = rtl818x_ioread8(priv,
priv-map-CONFIG3);
+ rtl818x_iowrite8(priv, priv-map-CONFIG3, reg |
RTL818X_CONFIG3_ANAPARAM_WRITE); + rtl818x_iowrite32(priv,
priv-map-ANAPARAM, RTL8225_ANAPARAM_ON); + rtl818x_iowrite32(priv,
priv-map-ANAPARAM2, RTL8225_ANAPARAM2_ON); + rtl818x_iowrite8(priv,
priv-map-CONFIG3, reg ~RTL818X_CONFIG3_ANAPARAM_WRITE);
+ rtl818x_iowrite8(priv, priv-map-EEPROM_CMD,
RTL818X_EEPROM_CMD_NORMAL); +
+ rtl818x_iowrite16(priv, priv-map-INT_MASK, 0);
+
+ mdelay(200);
+ rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x10);
+ rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x11);
+ rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x00);
+ mdelay(200);
ditto
also, kill the magic numbers
I have no idea what that does so I don't see the point in moving the number to
some define. However, the hardware does seem to work okay without this part
so I can remove it if you bothers you so much.
Regardless of any symbol issues, if it works without it, then remove it,
because it is pointless code. All pointless code should be removed.
But nonetheless, for any magic number registers that remain, give them
named constants that approximate their use as best as you can tell.
+ rtl818x_iowrite16(priv, priv-map-BRSR, 0x01F3);
+ reg = rtl818x_ioread16(priv, priv-map-PGSELECT) 0xfffe;
+ rtl818x_iowrite16(priv, priv-map-PGSELECT, reg | 0x1);
+
Re: [BUG][debian-2.6.20-1-686] bridging + vlans + vconfig rem == stuck kernel
Kyle Moffett wrote: vconfig D 83CCD8CE 0 16564 16562 (NOTLB) efdd7e7c 0086 ee120afb 83ccd8ce 98f00788 b7083ffa 5384b49a c76c0b05 9ebaf791 0004 efdd7e4e 0007 f1468a90 2ab74174 0362 0326 f1468b9c c180e420 0001 0286 c012933c efdd7e8c df98a000 c180e468 Call Trace: [c012933c] lock_timer_base+0x15/0x2f [c0129445] __mod_timer+0x91/0x9b [c02988f5] schedule_timeout+0x70/0x8d [f8b75209] vlan_device_event+0x13/0xf8 [8021q] Looks like a deadlock in the vlan code. Any chance you can run this test with lockdep enabled? You could also add a printk in vlan_device_event() to check which event it is hanging on, and the netdevice that is passed in. Since the vlan code holds RTNL at this point, then most other network tasks will eventually hang as well. Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - 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
