incorrect defines in mii.h
Hi all! The following defines are incorrect (include/linux/mii.h): #define BMSR_100FULL2 0x0200 /* Can do 100BASE-T2 HDX */ #define BMSR_100HALF2 0x0400 /* Can do 100BASE-T2 FDX */ it must be #define BMSR_100HALF2 0x0200 /* Can do 100BASE-T2 HDX */ #define BMSR_100FULL2 0x0400 /* Can do 100BASE-T2 FDX */ Best Regards, Matvejchikov Ilya. - 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 (take 2)] netdev: lockdep classes in register_netdevice Re: [patch 04/13] ppp_generic: fix lockdep warning
On Tue, May 15, 2007 at 11:17:51PM -0700, David Miller wrote: > From: Jarek Poplawski <[EMAIL PROTECTED]> > Date: Wed, 16 May 2007 08:17:32 +0200 > > > BTW - I think some patch on vlan cannot do any harm (at > > least like this previous of mine - with only ppp > > considered), and maybe this all could be forgotten. > > Let's wait to see if any new messages show up. > > I think how we've seperated PPP from ethernet locking > has annotated things sufficiently for lockdep to see > what's going on even in that VLAN case. > I'm 99,9% sure lockdep's warning like this will be back: #0 vlan_netdev_xmit_lock_key | V #1 ppp->wlock | V (pppoe) #0 ppp->wlock | V #1 pch->downl | V #2 vlan_netdev_xmit_lock_key | V (eth) This 0,1% is for Yuriy - when he changes config or turns off lockdep, like others. But I have no problem with waiting too. Jarek P. - 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 Tue, May 08, 2007 at 10:29:03AM +0200, Tomasz Chmielewski wrote: > Michael Jones wrote: > > >>+#ifndef __ARMEB__ > >>+#warning Little endian mode not supported > >>+#endif > > > >Personally I'm less fussed about WAN / LE support. Anyone with any > >sense will run ixp4xx boards doing such a specialised network > >operation as BE. Also, NSLU2-Linux can't test this functionality with > >our LE setup as we don't have this hardware on-board. You may just > >want to declare a depends on ARMEB in Kconfig (with or without OR > >(ARM || BROKEN) ) and have done with it - it's up to you. > > Christian Hohnstaedt's work did support LE though. > > Not all ixp4xx boards are by definition "doing such a specialised > network operation". > > > Krzysztof, why is LE not supported? > > Do you need access to ixp4xx that starts in LE mode? Not even trying to support LE is a clear merge blocker. Maybe Krzysztof can't actually test it himself, which is fine - but not even pretending to be endian clean is not what proper Linux drivers do. - 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: incorrect defines in mii.h
From: "Matvejchikov Ilya" <[EMAIL PROTECTED]> Date: Wed, 16 May 2007 11:01:04 +0400 > Hi all! > > The following defines are incorrect (include/linux/mii.h): > > #define BMSR_100FULL2 0x0200 /* Can do 100BASE-T2 HDX */ > #define BMSR_100HALF2 0x0400 /* Can do 100BASE-T2 FDX */ > > it must be > > #define BMSR_100HALF2 0x0200 /* Can do 100BASE-T2 HDX */ > #define BMSR_100FULL2 0x0400 /* Can do 100BASE-T2 FDX */ Thanks I will fix these. It is a good thing they are currently unused :-) - 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 16 May 2007, at 08:13, Christoph Hellwig wrote: Not even trying to support LE is a clear merge blocker. Maybe Krzysztof can't actually test it himself, which is fine - but not even pretending to be endian clean is not what proper Linux drivers do. w.r.t this comment, a working implementation LE implementation can be viewed here: http://www.hohnstaedt.de/ixp_npe/0.3.1/ixp4xx_npe_driver-0.3.1.diff Search in this file for "swap the payload of the SKB" (it's in mac_driver.c) Michael-Luke Jones - 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.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523
On Fri, 11 May 2007, Satyam Sharma wrote: > (later) > I Googled a bit to see if this problem was faced elsewhere in the kernel > too. Saw the following commit by Ingo Molnar > (9883a13c72dbf8c518814b6091019643cdb34429): > - lock_sock(sock->sk); > + local_bh_disable(); > + bh_lock_sock_nested(sock->sk); > rc = selinux_netlbl_socket_setsid(sock, sksec->sid); > - release_sock(sock->sk); > + bh_unlock_sock(sock->sk); > + local_bh_enable(); > Is it _really_ *this* simple? Hi Satyam, actually this *seems* to be proper solution also for our case, thanks for pointing this out. I will think about it once again, do some more tests with this locking scheme, and will let you know. Thanks, -- Jiri Kosina - 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 16, 2007 at 08:13:01AM +0100, Christoph Hellwig wrote: > > >>+#ifndef __ARMEB__ > > >>+#warning Little endian mode not supported > > >>+#endif > > > > > >Personally I'm less fussed about WAN / LE support. Anyone with any > > >sense will run ixp4xx boards doing such a specialised network > > >operation as BE. Also, NSLU2-Linux can't test this functionality with > > >our LE setup as we don't have this hardware on-board. You may just > > >want to declare a depends on ARMEB in Kconfig (with or without OR > > >(ARM || BROKEN) ) and have done with it - it's up to you. > > > > Christian Hohnstaedt's work did support LE though. > > > > Not all ixp4xx boards are by definition "doing such a specialised > > network operation". > > > > Krzysztof, why is LE not supported? > > > > Do you need access to ixp4xx that starts in LE mode? > > Not even trying to support LE is a clear merge blocker. Maybe > Krzysztof can't actually test it himself, which is fine - but > not even pretending to be endian clean is not what proper Linux > drivers do. The issue is not that the driver is not 'endian clean'. This is a driver for an on-chip ethernet MAC on an ARM CPU. I.e. the ethernet MAC is on the CPU itself, it's not some kind of PCI device or something like that. The ARM CPU in question can be run in either little endian or big endian mode. Making a driver work in both modes of operation is generally not just an issue of adding a couple of be32_to_cpu()s in the right places. For example, intel IXP2000 and IXP23xx CPU support in arch/arm only supports big-endian mode of operation, and none of the associated drivers support little-endian mode. Most of the other CPU support in arch/arm only supports little-endian mode, and none of the associated drivers support big-endian mode. According to your criterion, that would mean that most of the ARM drivers (alsa, usb, framebuffer, networking, etc.) should never have been accepted in the kernel tree in the first place. - 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 16 May 2007, at 10:41, Lennert Buytenhek wrote: Making a driver work in both modes of operation is generally not just an issue of adding a couple of be32_to_cpu()s in the right places. While this comment is technically correct, Christian's driver achieves endian agnostic operation with only 10 additional lines of code [1]. Thus, there is no reason to assume that gaining LE support will be a major issue. Michael-Luke [1] http://www.hohnstaedt.de/ixp_npe/0.3.1/ixp4xx_npe_driver-0.3.1.diff Search in this file for "swap the payload of the SKB" (it's in mac_driver.c) - 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
why we use skb->rt->rt_src as dest address when replying packet?
I found in function [ip_send_reply] and [icmp_reply], we use such code to get the destination address of our packet: struct rtable *rt = (struct rtable *)skb->dst; .. daddr = ipc.addr = rt->rt_src; I have a question here: Is there any special reason for using rt->rt_src as destination address? Can I use codes like these? struct iph * ip = skb->nh.iph; .. daddr = ipc.addr = ip->saddr; I found in some case, rt->rt_src is not equal to ip->saddr. 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: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lots of people wrote: > Lots of huffing and puffing about endian support by this driver ... For what it's worth, the NSLU2-Linux project (which has over 10,000 known users of our custom ixp4xx firmware, most of which will eventually be users of this new driver) is *endian-neutral*. We support both big-endian and little-endian usage of the ixp4xx in a number of consumer devices like the NSLU2, NAS100d, DSMG600, and FSG3. We are very interested in getting this driver into mainline in the most expedient and correct fashion acceptable to the relevant mainline maintainers. We have also discussed this situation with the author of the previous set of ixp4xx open-source ethernet driver patches, and he also recommends that we put our support behind this new set of patches. So, if the author of these patches wishes to concentrate on big-endian support first, then we will not say (and have not said) anything which will block inclusion of a big-endian only version of this driver. In parallel to this initial upstream push, we will be working with the author to make sure that this driver supports little-endian devices as well (as we are endian-neutral in our project's support of consumer devices based on the ixp4xx). If we get this done before upstream acceptance of the big-endian version, that will be great. If we don't, then we'll work to hit the next merge window. We will create a functionally correct little-endian version first (the simple byte-swapping implementation) and will work on a performance-enhanced version later (if that is even possible without prohibitive massive upstream changes). There simply is no reason for everyone to be arguing about this. Remember that what we are seeing here is an open-source replacement for a long-time proprietary driver. We should all rejoice in that, support the author of these patches, and not fight amongst ourselves. -- Rod Whitby -- NSLU2-Linux Project Lead - 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 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote: > So, if the author of these patches wishes to concentrate on big-endian > support first, then we will not say (and have not said) anything which > will block inclusion of a big-endian only version of this driver. The NSLU2 people are the ones here that are saying that the driver should really support LE (because that is what they happen to be using, the rest of the world runs the ixp4xx in BE), and they keep saying that it would be so easy to make a patch to add LE support, but so far they haven't produced such a patch. Please just write the patch and let's get this over with. - 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] ibm_emac: Correctly detect old link speed
This patch fixes a bug where the link speed change was not
detected correctly. This occured on a 440SPe (EMAC4) system
where the old link speed was 100Mbps and the new link speed
is 1000Mbps.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
commit 1e2a6085bbb6bd384e0812b6e9c62d18d14e1c0f
tree f441a914c9d66fb00fcde1e4bd7e02effba20dc7
parent 7b104bcb8e460e45a1aebe3da9b86aacdb4cab12
author Stefan Roese <[EMAIL PROTECTED]> Wed, 16 May 2007 12:54:40 +0200
committer Stefan Roese <[EMAIL PROTECTED]> Wed, 16 May 2007 12:54:40 +0200
drivers/net/ibm_emac/ibm_emac_core.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c
b/drivers/net/ibm_emac/ibm_emac_core.c
index 50035eb..ab38727 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -926,12 +926,18 @@ static int emac_link_differs(struct ocp_enet_private *dev)
int duplex = r & EMAC_MR1_FDE ? DUPLEX_FULL : DUPLEX_HALF;
int speed, pause, asym_pause;
- if (r & (EMAC_MR1_MF_1000 | EMAC_MR1_MF_1000GPCS))
- speed = SPEED_1000;
- else if (r & EMAC_MR1_MF_100)
- speed = SPEED_100;
- else
- speed = SPEED_10;
+ switch (r & EMAC_MR1_MF_MASK) {
+ case EMAC_MR1_MF_1000:
+ case EMAC_MR1_MF_1000GPCS:
+ speed = 1000;
+ break;
+ case EMAC_MR1_MF_10:
+ speed = 10;
+ break;
+ case EMAC_MR1_MF_100:
+ default:
+ speed = 100;
+ }
switch (r & (EMAC_MR1_EIFC | EMAC_MR1_APP)) {
case (EMAC_MR1_EIFC | EMAC_MR1_APP):
-
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][R8169] Add endianess annotations to [RT]xDesc
[R8169] Add endianess annotations to [RT]xDesc
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit 8b36037f072047e61557506ee917dcc25680bd69
tree faafe5e664affabef85ff4dcab280338fd528fae
parent b26c4a9f50ccfade25e3699f616ce97590dc2cb7
author Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 16 May 2007 08:23:39 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 16 May 2007 08:23:39 +0200
drivers/net/r8169.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 45876a8..2261835 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -405,15 +405,15 @@ enum _DescStatusBit {
#define RsvdMask 0x3fffc000
struct TxDesc {
- u32 opts1;
- u32 opts2;
- u64 addr;
+ __le32 opts1;
+ __le32 opts2;
+ __le64 addr;
};
struct RxDesc {
- u32 opts1;
- u32 opts2;
- u64 addr;
+ __le32 opts1;
+ __le32 opts2;
+ __le64 addr;
};
struct ring_info {
-
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.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523
Hi Jiri, On 5/16/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: On Fri, 11 May 2007, Satyam Sharma wrote: > (later) > I Googled a bit to see if this problem was faced elsewhere in the kernel > too. Saw the following commit by Ingo Molnar > (9883a13c72dbf8c518814b6091019643cdb34429): > - lock_sock(sock->sk); > + local_bh_disable(); > + bh_lock_sock_nested(sock->sk); > rc = selinux_netlbl_socket_setsid(sock, sksec->sid); > - release_sock(sock->sk); > + bh_unlock_sock(sock->sk); > + local_bh_enable(); > Is it _really_ *this* simple? [...] actually this *seems* to be proper solution also for our case, thanks for pointing this out. I will think about it once again, do some more tests with this locking scheme, and will let you know. Yes, I can almost confirm that this (open-coding of spin_lock_bh, effectively) is the proper solution (Rusty's unreliable guide to kernel-locking needs to be next to every developer's keyboard :-) I also came across this idiom in other places in the networking code so it seems to be pretty much the standard way. I wish I owned bluetooth hardware, could've tested this for you myself. Thanks, Satyam - 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: > On Wed, May 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote: >> So, if the author of these patches wishes to concentrate on big-endian >> support first, then we will not say (and have not said) anything which >> will block inclusion of a big-endian only version of this driver. > > The NSLU2 people are the ones here that are saying that the driver > should really support LE (because that is what they happen to be > using, the rest of the world runs the ixp4xx in BE) I'll repeat again. NSLU2-Linux supports both BE and LE. We have about 5,000 users running BE and about 5,000 users running LE. Perhaps you're confusing the NSLU2-Linux project (which official supports both endians equally) with the Debian project (which official supports only LE, and has an unofficial BE port). One NSLU2-Linux person said they would prefer the driver to support LE, but would be happy for it to be marked BE only in the Kconfig as an alternative. That is consistent with what I wrote in my message. > Please just write the patch and let's get this over with. Please let's just stop arguing about it. If a patch appears before it gets merged, then great. If it doesn't then it will appear at a later date. -- Rod - 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.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523
Hi Satayam, > > > (later) > > > I Googled a bit to see if this problem was faced elsewhere in the kernel > > > too. Saw the following commit by Ingo Molnar > > > (9883a13c72dbf8c518814b6091019643cdb34429): > > > - lock_sock(sock->sk); > > > + local_bh_disable(); > > > + bh_lock_sock_nested(sock->sk); > > > rc = selinux_netlbl_socket_setsid(sock, sksec->sid); > > > - release_sock(sock->sk); > > > + bh_unlock_sock(sock->sk); > > > + local_bh_enable(); > > > Is it _really_ *this* simple? > > [...] > > actually this *seems* to be proper solution also for our case, thanks for > > pointing this out. I will think about it once again, do some more tests > > with this locking scheme, and will let you know. > > Yes, I can almost confirm that this (open-coding of spin_lock_bh, > effectively) is the proper solution (Rusty's unreliable guide to > kernel-locking needs to be next to every developer's keyboard :-) > I also came across this idiom in other places in the networking code > so it seems to be pretty much the standard way. I wish I owned > bluetooth hardware, could've tested this for you myself. does this mean we should revert previous changes to the locking or only apply this on top of it? Regards Marcel - 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.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523
Hi Marcel,
On 5/16/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
Hi Satayam,
> > > (later)
> > > I Googled a bit to see if this problem was faced elsewhere in the kernel
> > > too. Saw the following commit by Ingo Molnar
> > > (9883a13c72dbf8c518814b6091019643cdb34429):
> > > - lock_sock(sock->sk);
> > > + local_bh_disable();
> > > + bh_lock_sock_nested(sock->sk);
> > > rc = selinux_netlbl_socket_setsid(sock, sksec->sid);
> > > - release_sock(sock->sk);
> > > + bh_unlock_sock(sock->sk);
> > > + local_bh_enable();
> > > Is it _really_ *this* simple?
> > [...]
> > actually this *seems* to be proper solution also for our case, thanks for
> > pointing this out. I will think about it once again, do some more tests
> > with this locking scheme, and will let you know.
>
> Yes, I can almost confirm that this (open-coding of spin_lock_bh,
> effectively) is the proper solution (Rusty's unreliable guide to
> kernel-locking needs to be next to every developer's keyboard :-)
> I also came across this idiom in other places in the networking code
> so it seems to be pretty much the standard way. I wish I owned
> bluetooth hardware, could've tested this for you myself.
does this mean we should revert previous changes to the locking or only
apply this on top of it?
I've fixed a simple patch on top of 2.6.22-rc1 below.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
diff -ruNp a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
--- a/net/bluetooth/hci_sock.c 2007-05-16 17:31:06.0 +0530
+++ b/net/bluetooth/hci_sock.c 2007-05-16 17:33:36.0 +0530
@@ -665,7 +665,8 @@ static int hci_sock_dev_event(struct not
/* Detach sockets from device */
read_lock(&hci_sk_list.lock);
sk_for_each(sk, node, &hci_sk_list.head) {
- lock_sock(sk);
+ local_bh_disable();
+ bh_lock_sock_nested(sk);
if (hci_pi(sk)->hdev == hdev) {
hci_pi(sk)->hdev = NULL;
sk->sk_err = EPIPE;
@@ -674,6 +675,8 @@ static int hci_sock_dev_event(struct not
hci_dev_put(hdev);
}
+ bh_unlock_sock(sk);
+ local_bh_enable();
release_sock(sk);
}
read_unlock(&hci_sk_list.lock);
-
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.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523
On 5/16/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
Hi Marcel,
[...]
> > > > (later)
> > > > I Googled a bit to see if this problem was faced elsewhere in the kernel
> > > > too. Saw the following commit by Ingo Molnar
> > > > (9883a13c72dbf8c518814b6091019643cdb34429):
> > > > - lock_sock(sock->sk);
> > > > + local_bh_disable();
> > > > + bh_lock_sock_nested(sock->sk);
> > > > rc = selinux_netlbl_socket_setsid(sock, sksec->sid);
> > > > - release_sock(sock->sk);
> > > > + bh_unlock_sock(sock->sk);
> > > > + local_bh_enable();
> > > > Is it _really_ *this* simple?
> > > [...]
> > > actually this *seems* to be proper solution also for our case, thanks for
> > > pointing this out. I will think about it once again, do some more tests
> > > with this locking scheme, and will let you know.
> >
> > Yes, I can almost confirm that this (open-coding of spin_lock_bh,
> > effectively) is the proper solution (Rusty's unreliable guide to
> > kernel-locking needs to be next to every developer's keyboard :-)
> > I also came across this idiom in other places in the networking code
> > so it seems to be pretty much the standard way. I wish I owned
> > bluetooth hardware, could've tested this for you myself.
>
> does this mean we should revert previous changes to the locking or only
> apply this on top of it?
I've fixed a simple patch on top of 2.6.22-rc1 below.
Eek, please ignore previous one. This one's correct.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
diff -ruNp a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
--- a/net/bluetooth/hci_sock.c 2007-05-16 17:31:06.0 +0530
+++ b/net/bluetooth/hci_sock.c 2007-05-16 17:38:35.0 +0530
@@ -665,7 +665,8 @@ static int hci_sock_dev_event(struct not
/* Detach sockets from device */
read_lock(&hci_sk_list.lock);
sk_for_each(sk, node, &hci_sk_list.head) {
- lock_sock(sk);
+ local_bh_disable();
+ bh_lock_sock_nested(sk);
if (hci_pi(sk)->hdev == hdev) {
hci_pi(sk)->hdev = NULL;
sk->sk_err = EPIPE;
@@ -674,7 +675,8 @@ static int hci_sock_dev_event(struct not
hci_dev_put(hdev);
}
- release_sock(sk);
+ bh_unlock_sock(sk);
+ local_bh_enable();
}
read_unlock(&hci_sk_list.lock);
}
-
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 16, 2007 at 09:05:18PM +0930, Rod Whitby wrote: > >> So, if the author of these patches wishes to concentrate on big-endian > >> support first, then we will not say (and have not said) anything which > >> will block inclusion of a big-endian only version of this driver. > > > > The NSLU2 people are the ones here that are saying that the driver > > should really support LE (because that is what they happen to be > > using, the rest of the world runs the ixp4xx in BE) > > I'll repeat again. NSLU2-Linux supports both BE and LE. We have > about 5,000 users running BE and about 5,000 users running LE. Perhaps, but somehow I don't think that we'd have seen any reaction if the submitted driver had only supported LE and not BE. > > Please just write the patch and let's get this over with. > > Please let's just stop arguing about it. If a patch appears before > it gets merged, then great. If it doesn't then it will appear at a > later date. Great. I agree. - 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.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523
Hi Satyam,
> > > > > > (later)
> > > > > > I Googled a bit to see if this problem was faced elsewhere in the
> > > > > > kernel
> > > > > > too. Saw the following commit by Ingo Molnar
> > > > > > (9883a13c72dbf8c518814b6091019643cdb34429):
> > > > > > - lock_sock(sock->sk);
> > > > > > + local_bh_disable();
> > > > > > + bh_lock_sock_nested(sock->sk);
> > > > > > rc = selinux_netlbl_socket_setsid(sock, sksec->sid);
> > > > > > - release_sock(sock->sk);
> > > > > > + bh_unlock_sock(sock->sk);
> > > > > > + local_bh_enable();
> > > > > > Is it _really_ *this* simple?
> > > > > [...]
> > > > > actually this *seems* to be proper solution also for our case, thanks
> > > > > for
> > > > > pointing this out. I will think about it once again, do some more
> > > > > tests
> > > > > with this locking scheme, and will let you know.
> > > >
> > > > Yes, I can almost confirm that this (open-coding of spin_lock_bh,
> > > > effectively) is the proper solution (Rusty's unreliable guide to
> > > > kernel-locking needs to be next to every developer's keyboard :-)
> > > > I also came across this idiom in other places in the networking code
> > > > so it seems to be pretty much the standard way. I wish I owned
> > > > bluetooth hardware, could've tested this for you myself.
> > >
> > > does this mean we should revert previous changes to the locking or only
> > > apply this on top of it?
> >
> > I've fixed a simple patch on top of 2.6.22-rc1 below.
>
> Eek, please ignore previous one. This one's correct.
>
> Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
>
> diff -ruNp a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
> --- a/net/bluetooth/hci_sock.c2007-05-16 17:31:06.0 +0530
> +++ b/net/bluetooth/hci_sock.c2007-05-16 17:38:35.0 +0530
> @@ -665,7 +665,8 @@ static int hci_sock_dev_event(struct not
> /* Detach sockets from device */
> read_lock(&hci_sk_list.lock);
> sk_for_each(sk, node, &hci_sk_list.head) {
> - lock_sock(sk);
> + local_bh_disable();
> + bh_lock_sock_nested(sk);
> if (hci_pi(sk)->hdev == hdev) {
> hci_pi(sk)->hdev = NULL;
> sk->sk_err = EPIPE;
> @@ -674,7 +675,8 @@ static int hci_sock_dev_event(struct not
>
> hci_dev_put(hdev);
> }
> - release_sock(sk);
> + bh_unlock_sock(sk);
> + local_bh_enable();
> }
> read_unlock(&hci_sk_list.lock);
> }
since Jiri has a good test case for it, I leave it to him for testing.
If he confirms that this fixes the locking issues, then this is
Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]>
Regards
Marcel
-
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.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523
On Wed, 16 May 2007, Marcel Holtmann wrote: > since Jiri has a good test case for it, I leave it to him for testing. > If he confirms that this fixes the locking issues, then this is > Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> I will verify later this evening and will let you know. I am however pretty convinced now that this is the right fix. Thanks, -- Jiri Kosina - 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] small netdevices.txt fix
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> Index: linux-2.6/Documentation/networking/netdevices.txt === --- linux-2.6.orig/Documentation/networking/netdevices.txt 2007-01-04 19:38:05.0 +0100 +++ linux-2.6/Documentation/networking/netdevices.txt 2007-01-04 19:40:22.0 +0100 @@ -49,7 +49,7 @@ for this and return -1 when the spin lock fails. The locking there should also properly protect against set_multicast_list - Context: BHs disabled + Context: Process with BHs disabled or BH (timer). Notes: netif_queue_stopped() is guaranteed false Interrupts must be enabled when calling hard_start_xmit. (Interrupts must also be enabled when enabling the BH handler.) - 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: node-aware skbuff allocation
Spidernet was the driver I original did all the node-aware netdevice
allocation for, but after a year it still hasn't hit mainline.
So here's the patch again:
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/net/spider_net.c
===
--- linux-2.6.orig/drivers/net/spider_net.c 2006-10-23 17:20:14.0
+0200
+++ linux-2.6/drivers/net/spider_net.c 2006-10-30 13:27:48.0 +0100
@@ -395,7 +395,8 @@
/* and we need to have it 128 byte aligned, therefore we allocate a
* bit more */
/* allocate an skb */
- descr->skb = dev_alloc_skb(bufsize + SPIDER_NET_RXBUF_ALIGN - 1);
+ descr->skb = netdev_alloc_skb(card->netdev,
+ bufsize + SPIDER_NET_RXBUF_ALIGN - 1);
if (!descr->skb) {
if (netif_msg_rx_err(card) && net_ratelimit())
pr_err("Not enough memory to allocate rx buffer\n");
-
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
Purpose of bit shifts in tcp_get_info
Dear Community, I was wondering what the purpose of the bit shifts in tcp_get_info right after the jiffies conversion might be. What's the time unit after that shift? info->tcpi_rtt = jiffies_to_usecs(tp->srtt)>>3; info->tcpi_rttvar = jiffies_to_usecs(tp->mdev)>>2; [...] info->tcpi_rcv_rtt = jiffies_to_usecs(tp->rcv_rtt_est.rtt)>>3; Maybe somebody has a hint for me? Thanks a lot! Daniel - 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
Christoph Hellwig <[EMAIL PROTECTED]> writes: > Not even trying to support LE is a clear merge blocker. Maybe Krzysztof > can't actually test it himself, which is fine - but not even pretending > to be endian clean is not what proper Linux drivers do. The drivers can only work with IXP4xx CPU and that's not the typical endianess problem cross-platform drivers sometimes have. There is different functionality required with LE mode, unless some other arch changes are implemented (which I'm now researching, if I have some time of course). -- Krzysztof Halasa - 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
Rod Whitby <[EMAIL PROTECTED]> writes: > Please let's just stop arguing about it. If a patch appears before it > gets merged, then great. If it doesn't then it will appear at a later date. Sure. The "swapping" patch is trivial and I can add it if needed at some point but I hope we can do that "data coherency mode" right. Personally I'd be pleased if I could run the board LE instead of BE, with no performance penalty. -- Krzysztof Halasa - 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 0/7] CAN: Add new PF_CAN protocol family
This patch series applies against linux-2.6.22-rc1-git4. It adds a new protocol family to Linux for communication on the CAN (Controller Area Network) using the socket API. The current implementation supports two protocols in the family, a raw protocol for sending and receiving raw CAN frames, and a broadcast manager protocol, which effeciently handles periodically sent broadcast messages, which are typical in CAN environments. There is also a virtual CAN network driver which only loops back sent CAN frames. Drivers for real CAN hardware are also being worked on and are nearly complete. These will be released later, or you can find them in the subversion repository at http://svn.berlios.de/svnroot/repos/socketcan. Additional information about the concepts of the CAN protocol family can be found in the file Documentation/networking/can.txt, added by patch 7/7. Userspace tools (can-utils) and test suites for the different CAN protocols can also be found in the subversion repository. -- - 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 6/7] CAN: Add maintainer entries
This patch adds entries in the CREDITS and MAINTAINERS file for CAN. Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]> Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]> --- CREDITS | 16 MAINTAINERS |9 + 2 files changed, 25 insertions(+) Index: linux-2.6.22-rc1-git4/CREDITS === --- linux-2.6.22-rc1-git4.orig/CREDITS 2007-05-16 09:33:39.0 +0200 +++ linux-2.6.22-rc1-git4/CREDITS 2007-05-16 09:34:51.0 +0200 @@ -1330,6 +1330,14 @@ S: 5623 HZ Eindhoven S: The Netherlands +N: Oliver Hartkopp +E: [EMAIL PROTECTED] +W: http://www.volkswagen.de +D: Controller Area Network (network layer core) +S: Brieffach 1776 +S: 38436 Wolfsburg +S: Germany + N: Andrew Haylett E: [EMAIL PROTECTED] D: Selection mechanism @@ -3283,6 +3291,14 @@ S: F-35042 Rennes Cedex S: France +N: Urs Thuermann +E: [EMAIL PROTECTED] +W: http://www.volkswagen.de +D: Controller Area Network (network layer core) +S: Brieffach 1776 +S: 38436 Wolfsburg +S: Germany + N: Jon Tombs E: [EMAIL PROTECTED] W: http://www.esi.us.es/~jon Index: linux-2.6.22-rc1-git4/MAINTAINERS === --- linux-2.6.22-rc1-git4.orig/MAINTAINERS 2007-05-16 09:34:02.0 +0200 +++ linux-2.6.22-rc1-git4/MAINTAINERS 2007-05-16 09:34:51.0 +0200 @@ -931,6 +931,15 @@ L: [EMAIL PROTECTED] S: Maintained +CAN NETWORK LAYER +P: Urs Thuermann +M: [EMAIL PROTECTED] +P: Oliver Hartkopp +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: http://developer.berlios.de/projects/socketcan/ +S: Maintained + CALGARY x86-64 IOMMU P: Muli Ben-Yehuda M: [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 1/7] CAN: Allocate protocol numbers for PF_CAN
This patch adds a protocol/address family number, ARP hardware type, ethernet packet type, and a line discipline number for the SocketCAN implementation. Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]> Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]> --- include/linux/if_arp.h |1 + include/linux/if_ether.h |1 + include/linux/socket.h |2 ++ include/linux/tty.h |3 ++- 4 files changed, 6 insertions(+), 1 deletion(-) Index: linux-2.6.22-rc1-git4/include/linux/if_arp.h === --- linux-2.6.22-rc1-git4.orig/include/linux/if_arp.h 2007-05-16 09:33:50.0 +0200 +++ linux-2.6.22-rc1-git4/include/linux/if_arp.h2007-05-16 09:34:18.0 +0200 @@ -52,6 +52,7 @@ #define ARPHRD_ROSE270 #define ARPHRD_X25 271 /* CCITT X.25 */ #define ARPHRD_HWX25 272 /* Boards with X.25 in firmware */ +#define ARPHRD_CAN 280 /* Controller Area Network */ #define ARPHRD_PPP 512 #define ARPHRD_CISCO 513 /* Cisco HDLC */ #define ARPHRD_HDLCARPHRD_CISCO Index: linux-2.6.22-rc1-git4/include/linux/if_ether.h === --- linux-2.6.22-rc1-git4.orig/include/linux/if_ether.h 2007-05-16 09:33:50.0 +0200 +++ linux-2.6.22-rc1-git4/include/linux/if_ether.h 2007-05-16 09:34:18.0 +0200 @@ -89,6 +89,7 @@ #define ETH_P_WAN_PPP 0x0007 /* Dummy type for WAN PPP frames*/ #define ETH_P_PPP_MP0x0008 /* Dummy type for PPP MP frames */ #define ETH_P_LOCALTALK 0x0009 /* Localtalk pseudo type*/ +#define ETH_P_CAN 0x000C /* Controller Area Network */ #define ETH_P_PPPTALK 0x0010 /* Dummy type for Atalk over PPP*/ #define ETH_P_TR_802_2 0x0011 /* 802.2 frames */ #define ETH_P_MOBITEX 0x0015 /* Mobitex ([EMAIL PROTECTED]) */ Index: linux-2.6.22-rc1-git4/include/linux/socket.h === --- linux-2.6.22-rc1-git4.orig/include/linux/socket.h 2007-05-16 09:33:50.0 +0200 +++ linux-2.6.22-rc1-git4/include/linux/socket.h2007-05-16 09:34:18.0 +0200 @@ -185,6 +185,7 @@ #define AF_PPPOX 24 /* PPPoX sockets*/ #define AF_WANPIPE 25 /* Wanpipe API Sockets */ #define AF_LLC 26 /* Linux LLC*/ +#define AF_CAN 29 /* Controller Area Network */ #define AF_TIPC30 /* TIPC sockets */ #define AF_BLUETOOTH 31 /* Bluetooth sockets*/ #define AF_IUCV32 /* IUCV sockets */ @@ -220,6 +221,7 @@ #define PF_PPPOX AF_PPPOX #define PF_WANPIPE AF_WANPIPE #define PF_LLC AF_LLC +#define PF_CAN AF_CAN #define PF_TIPCAF_TIPC #define PF_BLUETOOTH AF_BLUETOOTH #define PF_IUCVAF_IUCV Index: linux-2.6.22-rc1-git4/include/linux/tty.h === --- linux-2.6.22-rc1-git4.orig/include/linux/tty.h 2007-05-16 09:33:50.0 +0200 +++ linux-2.6.22-rc1-git4/include/linux/tty.h 2007-05-16 09:34:18.0 +0200 @@ -24,7 +24,7 @@ #define NR_PTYSCONFIG_LEGACY_PTY_COUNT /* Number of legacy ptys */ #define NR_UNIX98_PTY_DEFAULT 4096 /* Default maximum for Unix98 ptys */ #define NR_UNIX98_PTY_MAX (1 << MINORBITS) /* Absolute limit */ -#define NR_LDISCS 17 +#define NR_LDISCS 18 /* line disciplines */ #define N_TTY 0 @@ -45,6 +45,7 @@ #define N_SYNC_PPP 14 /* synchronous PPP */ #define N_HCI 15 /* Bluetooth HCI UART */ #define N_GIGASET_M101 16 /* Siemens Gigaset M101 serial DECT adapter */ +#define N_SLCAN17 /* Serial / USB serial CAN Adaptors */ /* * This character is the same as _POSIX_VDISABLE: it cannot be used as -- - 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 5/7] CAN: Add virtual CAN netdevice driver
This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.
Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]>
---
drivers/net/Makefile |1
drivers/net/can/Kconfig | 25 +++
drivers/net/can/Makefile |5
drivers/net/can/vcan.c | 308 +++
net/can/Kconfig |3
5 files changed, 342 insertions(+)
Index: linux-2.6.22-rc1-git4/drivers/net/Makefile
===
--- linux-2.6.22-rc1-git4.orig/drivers/net/Makefile 2007-05-16
09:44:54.0 +0200
+++ linux-2.6.22-rc1-git4/drivers/net/Makefile 2007-05-16 09:45:00.0
+0200
@@ -8,6 +8,7 @@
obj-$(CONFIG_CHELSIO_T1) += chelsio/
obj-$(CONFIG_CHELSIO_T3) += cxgb3/
obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
obj-$(CONFIG_BONDING) += bonding/
obj-$(CONFIG_ATL1) += atl1/
obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: linux-2.6.22-rc1-git4/drivers/net/can/Kconfig
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.22-rc1-git4/drivers/net/can/Kconfig 2007-05-16
09:45:00.0 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+ depends on CAN
+
+config CAN_VCAN
+ tristate "Virtual Local CAN Interface (vcan)"
+ depends on CAN
+ default N
+ ---help---
+ Similar to the network loopback devices, vcan offers a
+ virtual local CAN interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called vcan.
+
+config CAN_DEBUG_DEVICES
+ bool "CAN devices debugging messages"
+ depends on CAN
+ default N
+ ---help---
+ Say Y here if you want the CAN device drivers to produce a bunch of
+ debug messages to the system log. Select this if you are having
+ a problem with CAN support and want to see more of what is going
+ on.
+
+endmenu
Index: linux-2.6.22-rc1-git4/drivers/net/can/Makefile
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.22-rc1-git4/drivers/net/can/Makefile 2007-05-16
09:45:00.0 +0200
@@ -0,0 +1,5 @@
+#
+# Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN) += vcan.o
Index: linux-2.6.22-rc1-git4/drivers/net/can/vcan.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.22-rc1-git4/drivers/net/can/vcan.c2007-05-16
09:55:30.0 +0200
@@ -0,0 +1,308 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, the following disclaimer and
+ *the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+#includ
Re: [PATCH] [e1000] Lower the MSI unavailable message to INFO priority
Jeff Garzik wrote:
H. Peter Anvin wrote:
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 637ae8f..089ae3f 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -307,7 +307,7 @@ static int e1000_request_irq(struct e1000_adapter *adapter)
if (adapter->hw.mac_type >= e1000_82571) {
adapter->have_msi = TRUE;
if ((err = pci_enable_msi(adapter->pdev))) {
- DPRINTK(PROBE, ERR,
+ DPRINTK(PROBE, INFO,
"Unable to allocate MSI interrupt Error: %d\n", err);
adapter->have_msi = FALSE;
Actually, it should not print any message at all.
pci_enable_msi() failure is a normal event (as you point out). Even at
KERN_INFO level, the message is still misleading.
I've been reworking some of this code and there is even a pci_disable_msi()
missing in case pci_request_irq failed. I'll post a patch to clean it up in a
second.
Cheers,
Auke
-
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 3/7] CAN: Add raw protocol
This patch adds the CAN raw protocol.
Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]>
---
include/linux/can/raw.h | 31 ++
net/can/Kconfig | 26 +
net/can/Makefile|3
net/can/raw.c | 703
4 files changed, 763 insertions(+)
Index: linux-2.6.22-rc1-git4/include/linux/can/raw.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.22-rc1-git4/include/linux/can/raw.h 2007-05-16
09:57:38.0 +0200
@@ -0,0 +1,31 @@
+/*
+ * linux/can/raw.h
+ *
+ * Definitions for raw CAN sockets
+ *
+ * Authors: Oliver Hartkopp <[EMAIL PROTECTED]>
+ * Urs Thuermann <[EMAIL PROTECTED]>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to <[EMAIL PROTECTED]>
+ *
+ */
+
+#ifndef CAN_RAW_H
+#define CAN_RAW_H
+
+#include
+
+#define SOL_CAN_RAW (SOL_CAN_BASE + CAN_RAW)
+
+/* for socket options affecting the socket (not the global system) */
+
+enum {
+ CAN_RAW_FILTER = 1, /* set 0 .. n can_filter(s) */
+ CAN_RAW_ERR_FILTER, /* set filter for error frames */
+ CAN_RAW_LOOPBACK, /* local loopback (default:on) */
+ CAN_RAW_RECV_OWN_MSGS /* receive my own msgs (default:off) */
+};
+
+#endif
Index: linux-2.6.22-rc1-git4/net/can/Kconfig
===
--- linux-2.6.22-rc1-git4.orig/net/can/Kconfig 2007-05-16 09:57:33.0
+0200
+++ linux-2.6.22-rc1-git4/net/can/Kconfig 2007-05-16 09:57:38.0
+0200
@@ -16,6 +16,32 @@
If you want CAN support, you should say Y here and also to the
specific driver for your controller(s) below.
+config CAN_RAW
+ tristate "Raw CAN Protocol (raw access with CAN-ID filtering)"
+ depends on CAN
+ default N
+ ---help---
+ The Raw CAN protocol option offers access to the CAN bus via
+ the BSD socket API. You probably want to use the raw socket in
+ most cases where no higher level protocol is being used. The raw
+ socket has several filter options e.g. ID-Masking / Errorframes.
+ To receive/send raw CAN messages, use AF_CAN with protocol CAN_RAW.
+
+config CAN_RAW_USER
+ bool "Allow non-root users to access Raw CAN Protocol sockets"
+ depends on CAN_RAW
+ default N
+ ---help---
+ The Controller Area Network is a local field bus transmitting only
+ broadcast messages without any routing and security concepts.
+ In the majority of cases the user application has to deal with
+ raw CAN frames. Therefore it might be reasonable NOT to restrict
+ the CAN access only to the user root, as known from other networks.
+ Since CAN_RAW sockets can only send and receive frames to/from CAN
+ interfaces this does not affect security of others networks.
+ Say Y here if you want non-root users to be able to access CAN_RAW
+ sockets.
+
config CAN_DEBUG_CORE
bool "CAN Core debugging messages"
depends on CAN
Index: linux-2.6.22-rc1-git4/net/can/Makefile
===
--- linux-2.6.22-rc1-git4.orig/net/can/Makefile 2007-05-16 09:57:33.0
+0200
+++ linux-2.6.22-rc1-git4/net/can/Makefile 2007-05-16 09:57:38.0
+0200
@@ -4,3 +4,6 @@
obj-$(CONFIG_CAN) += can.o
can-objs := af_can.o proc.o
+
+obj-$(CONFIG_CAN_RAW) += can-raw.o
+can-raw-objs := raw.o
Index: linux-2.6.22-rc1-git4/net/can/raw.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.22-rc1-git4/net/can/raw.c 2007-05-16 09:58:40.0 +0200
@@ -0,0 +1,703 @@
+/*
+ * raw.c - Raw sockets for protocol family CAN
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, the following disclaimer and
+ *the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms o
[patch 7/7] CAN: Add documentation
This patch adds documentation for the PF_CAN protocol family. Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]> Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]> --- Documentation/networking/can.txt | 635 +++ 1 file changed, 635 insertions(+) Index: linux-2.6.22-rc1-git4/Documentation/networking/can.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.22-rc1-git4/Documentation/networking/can.txt 2007-05-16 10:50:53.0 +0200 @@ -0,0 +1,635 @@ + + +can.txt + +Readme file for the Controller Area Network Protocol Family (aka Socket CAN) + +This file contains + + 1 Overview / What is Socket CAN + + 2 Motivation / Why using the socket API + + 3 Socket CAN concept +3.1 receive lists +3.2 loopback +3.3 network security issues (capabilities) +3.4 network problem notifications + + 4 How to use Socket CAN +4.1 RAW protocol sockets with can_filters (SOCK_RAW) + 4.1.1 RAW socket option CAN_RAW_FILTER + 4.1.2 RAW socket option CAN_RAW_ERR_FILTER + 4.1.3 RAW socket option CAN_RAW_LOOPBACK + 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS +4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) +4.3 connected transport protocols (SOCK_SEQPACKET) +4.4 unconnected transport protocols (SOCK_DGRAM) + + 5 Socket CAN core module +5.1 can.ko module params +5.2 procfs content +5.3 writing own CAN protocol modules + + 6 CAN network drivers +6.1 general settings +6.2 loopback +6.3 CAN controller hardware filters +6.4 currently supported CAN hardware +6.5 todo + + 7 Credits + + + +1. Overview / What is Socket CAN + + +The socketcan package is an implementation of CAN protocols +(Controller Area Network) for Linux. CAN is a networking technology +which has wide-spread use in automation, embedded devices, and +automotive fields. While there have been other CAN implementations +for Linux based on character devices, Socket CAN uses the Berkeley +socket API, the Linux network stack and implements the CAN device +drivers as network interfaces. The CAN socket API has been designed +as similar as possible to the TCP/IP protocols to allow programmers, +familiar with network programming, to easily learn how to use CAN +sockets. + +2. Motivation / Why using the socket API + + +There have been CAN implementations for Linux before Socket CAN so the +question arises, why we have started another project. Most existing +implementations come as a device driver for some CAN hardware, they +are based on character devices and provide comparatively little +functionality. Usually, there is only a hardware-specific device +driver which provides a character device interface to send and +receive raw CAN frames, directly to/from the controller hardware. +Queueing of frames and higher-level transport protocols like ISO-TP +have to be implemented in user space applications. Also, most +character-device implementations support only one single process to +open the device at a time, similar to a serial interface. Exchanging +the CAN controller requires employment of another device driver and +often the need for adaption of large parts of the application to the +new driver's API. + +Socket CAN was designed to overcome all of these limitations. A new +protocol family has been implemented which provides a socket interface +to user space applications and which builds upon the Linux network +layer, so to use all of the provided queueing functionality. Device +drivers for CAN controller hardware register itself with the Linux +network layer as a network device, so that CAN frames from the +controller can be passed up to the network layer and on to the CAN +protocol family module and also vice-versa. Also, the protocol family +module provides an API for transport protocol modules to register, so +that any number of transport protocols can be loaded or unloaded +dynamically. In fact, the can core module alone does not provide any +protocol and can not be used without loading at least one additional +protocol module. Multiple sockets can be opened at the same time, +on different or the same protocol module and they can listen/send +frames on different or the same CAN IDs. Several sockets listening on +the same interface for frames with the same CAN ID are all passed the +same received matching CAN frames. An application wishing to +communicate using a specific transport protocol, e.g. ISO-TP, just +selects that protocol when opening the socket, and then can read and +write application data byte streams, without having to deal with +CAN-IDs, frames, etc. + +Similar functionality visible from user-space could be provide
[patch 4/7] CAN: Add broadcast manager (bcm) protocol
This patch adds the CAN broadcast manager (bcm) protocol.
Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]>
---
include/linux/can/bcm.h | 65 +
net/can/Kconfig | 28
net/can/Makefile|3
net/can/bcm.c | 1671
4 files changed, 1767 insertions(+)
Index: linux-2.6.22-rc1-git4/include/linux/can/bcm.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.22-rc1-git4/include/linux/can/bcm.h 2007-05-16
09:59:57.0 +0200
@@ -0,0 +1,65 @@
+/*
+ * linux/can/bcm.h
+ *
+ * Definitions for CAN Broadcast Manager (BCM)
+ *
+ * Author: Oliver Hartkopp <[EMAIL PROTECTED]>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to <[EMAIL PROTECTED]>
+ *
+ */
+
+#ifndef CAN_BCM_H
+#define CAN_BCM_H
+
+/**
+ * struct bcm_msg_head - head of messages to/from the broadcast manager
+ * @opcode:opcode, see enum below.
+ * @flags: special flags, see below.
+ * @count: number of frames to send before changing interval.
+ * @ival1: interval for the first @count frames.
+ * @ival2: interval for the following frames.
+ * @can_id:CAN ID of frames to be sent or received.
+ * @nframes: number of frames appended to the message head.
+ * @frames:array of CAN frames.
+ */
+struct bcm_msg_head {
+ int opcode;
+ int flags;
+ int count;
+ struct timeval ival1, ival2;
+ canid_t can_id;
+ int nframes;
+ struct can_frame frames[0];
+};
+
+enum {
+ TX_SETUP = 1, /* create (cyclic) transmission task */
+ TX_DELETE, /* remove (cyclic) transmission task */
+ TX_READ,/* read properties of (cyclic) transmission task */
+ TX_SEND,/* send one CAN frame */
+ RX_SETUP, /* create RX content filter subscription */
+ RX_DELETE, /* remove RX content filter subscription */
+ RX_READ,/* read properties of RX content filter subscription */
+ TX_STATUS, /* reply to TX_READ request */
+ TX_EXPIRED, /* notification on performed transmissions (count=0) */
+ RX_STATUS, /* reply to RX_READ request */
+ RX_TIMEOUT, /* cyclic message is absent */
+ RX_CHANGED /* updated CAN frame (detected content change) */
+};
+
+#define SETTIMER0x0001
+#define STARTTIMER 0x0002
+#define TX_COUNTEVT 0x0004
+#define TX_ANNOUNCE 0x0008
+#define TX_CP_CAN_ID0x0010
+#define RX_FILTER_ID0x0020
+#define RX_CHECK_DLC0x0040
+#define RX_NO_AUTOTIMER 0x0080
+#define RX_ANNOUNCE_RESUME 0x0100
+#define TX_RESET_MULTI_IDX 0x0200
+#define RX_RTR_FRAME0x0400
+
+#endif /* CAN_BCM_H */
Index: linux-2.6.22-rc1-git4/net/can/Kconfig
===
--- linux-2.6.22-rc1-git4.orig/net/can/Kconfig 2007-05-16 09:57:38.0
+0200
+++ linux-2.6.22-rc1-git4/net/can/Kconfig 2007-05-16 09:59:57.0
+0200
@@ -42,6 +42,34 @@
Say Y here if you want non-root users to be able to access CAN_RAW
sockets.
+config CAN_BCM
+ tristate "Broadcast Manager CAN Protocol (with content filtering)"
+ depends on CAN
+ default N
+ ---help---
+ The Broadcast Manager offers content filtering, timeout monitoring,
+ sending of RTR-frames and cyclic CAN messages without permanent user
+ interaction. The BCM can be 'programmed' via the BSD socket API and
+ informs you on demand e.g. only on content updates / timeouts.
+ You probably want to use the bcm socket in most cases where cyclic
+ CAN messages are used on the bus (e.g. in automotive environments).
+ To use the Broadcast Manager, use AF_CAN with protocol CAN_BCM.
+
+config CAN_BCM_USER
+ bool "Allow non-root users to access CAN broadcast manager sockets"
+ depends on CAN_BCM
+ default N
+ ---help---
+ The Controller Area Network is a local field bus transmitting only
+ broadcast messages without any routing and security concepts.
+ In the majority of cases the user application has to deal with
+ raw CAN frames. Therefore it might be reasonable NOT to restrict
+ the CAN access only to the user root, as known from other networks.
+ Since CAN_BCM sockets can only send and receive frames to/from CAN
+ interfaces this does not affect security of others networks.
+ Say Y here if you want non-root users to be able to access CAN_BCM
+ sockets.
+
config CAN_DEBUG_CORE
bool "CAN Core debugging messages"
depends on CAN
Index: linux-2.6.22-rc1-git4/net/can/Makefile
===
--- linux-2.6.22-rc1-
[PATCH] e1000: Fix msi enable leak on error, don't print error message, cleanup
pci_enable_msi failure is a normal event so we should not print any error.
Going over the code I spotted a missing pci_disable_msi() leak when irq
allocation fails. The whole code also needed a cleanup, so I combined the
two different calls to pci_request_irq into a single call making this
look a lot better.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Cc: H. Peter Anvin <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 32 +++-
1 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 637ae8f..b2c5b8e 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -300,31 +300,29 @@ module_exit(e1000_exit_module);
static int e1000_request_irq(struct e1000_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
- int flags, err = 0;
+ void (*handler) = &e1000_intr;
+ int irq_flags = IRQF_SHARED;
+ int err;
- flags = IRQF_SHARED;
#ifdef CONFIG_PCI_MSI
if (adapter->hw.mac_type >= e1000_82571) {
- adapter->have_msi = TRUE;
- if ((err = pci_enable_msi(adapter->pdev))) {
- DPRINTK(PROBE, ERR,
-"Unable to allocate MSI interrupt Error: %d\n", err);
- adapter->have_msi = FALSE;
+ adapter->have_msi = !pci_enable_msi(adapter->pdev);
+ if (adapter->have_msi) {
+ handler = &e1000_intr_msi;
+ irq_flags = 0;
}
}
- if (adapter->have_msi) {
- flags &= ~IRQF_SHARED;
- err = request_irq(adapter->pdev->irq, &e1000_intr_msi, flags,
- netdev->name, netdev);
- if (err)
- DPRINTK(PROBE, ERR,
- "Unable to allocate interrupt Error: %d\n", err);
- } else
#endif
- if ((err = request_irq(adapter->pdev->irq, &e1000_intr, flags,
- netdev->name, netdev)))
+ err = request_irq(adapter->pdev->irq, handler, irq_flags, netdev->name,
+ netdev);
+ if (err) {
+#ifdef CONFIG_PCI_MSI
+ if (adapter->have_msi)
+ pci_disable_msi(adapter->pdev);
+#endif
DPRINTK(PROBE, ERR,
"Unable to allocate interrupt Error: %d\n", err);
+ }
return err;
}
-
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] e1000: Fix msi enable leak on error, don't print error message, cleanup
Auke Kok wrote: pci_enable_msi failure is a normal event so we should not print any error. Going over the code I spotted a missing pci_disable_msi() leak when irq allocation fails. The whole code also needed a cleanup, so I combined the two different calls to pci_request_irq into a single call making this look a lot better. Signed-off-by: Auke Kok <[EMAIL PROTECTED]> Cc: H. Peter Anvin <[EMAIL PROTECTED]> Looks OK, but compounds (and highlights) another problem: you shouldn't be adding CONFIG_PCI_MSI ifdefs to the code. MSI support is properly set up in the headers to enable working code even if CONFIG_PCI_MSI is disabled. Revise your patch to remove CONFIG_PCI_MSI tests, and I'll include it straightaway. 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] e1000: Fix msi enable leak on error, don't print error message, cleanup
Jeff Garzik wrote: Auke Kok wrote: pci_enable_msi failure is a normal event so we should not print any error. Going over the code I spotted a missing pci_disable_msi() leak when irq allocation fails. The whole code also needed a cleanup, so I combined the two different calls to pci_request_irq into a single call making this look a lot better. Signed-off-by: Auke Kok <[EMAIL PROTECTED]> Cc: H. Peter Anvin <[EMAIL PROTECTED]> Looks OK, but compounds (and highlights) another problem: you shouldn't be adding CONFIG_PCI_MSI ifdefs to the code. MSI support is properly set up in the headers to enable working code even if CONFIG_PCI_MSI is disabled. Revise your patch to remove CONFIG_PCI_MSI tests, and I'll include it straightaway. OK, on its way. Thanks. Auke - 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: select(0, ..) is valid ?
Hi Hugh, > It's interesting that compat_core_sys_select() shows this kmalloc(0) > failure but core_sys_select() does not. That's because core_sys_select() > avoids kmalloc by using a buffer on the stack for small allocations (and > 0 sure is small). Shouldn't compat_core_sys_select() do just the same? > Or is SLUB going to be so efficient that doing so is a waste of time? Nice catch, the original optimisation from Andi is: http://git.kernel.org/git-new/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=70674f95c0a2ea694d5c39f4e514f538a09be36f And I think it makes sense for the compat code to do it too. Anton - 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] e1000: Fix msi enable leak on error, don't print error message, cleanup
pci_enable_msi failure is a normal event so we should not print any error.
Going over the code I spotted a missing pci_disable_msi() leak when irq
allocation fails. The whole code also needed a cleanup, so I combined the
two different calls to pci_request_irq into a single call making this
look a lot better. All #ifdef CONFIG_PCI_MSI's have been removed.
Compile tested with both CONFIG_PCI_MSI enabled and disabled.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Cc: H. Peter Anvin <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000.h |4 +---
drivers/net/e1000/e1000_main.c | 39 ++-
2 files changed, 15 insertions(+), 28 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index a9ea67e..16a6edf 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -333,11 +333,9 @@ struct e1000_adapter {
struct e1000_tx_ring test_tx_ring;
struct e1000_rx_ring test_rx_ring;
-
int msg_enable;
-#ifdef CONFIG_PCI_MSI
boolean_t have_msi;
-#endif
+
/* to not mess up cache alignment, always add to the bottom */
boolean_t tso_force;
boolean_t smart_power_down; /* phy smart power down */
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 637ae8f..49be393 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -158,9 +158,7 @@ static struct net_device_stats * e1000_get_stats(struct
net_device *netdev);
static int e1000_change_mtu(struct net_device *netdev, int new_mtu);
static int e1000_set_mac(struct net_device *netdev, void *p);
static irqreturn_t e1000_intr(int irq, void *data);
-#ifdef CONFIG_PCI_MSI
static irqreturn_t e1000_intr_msi(int irq, void *data);
-#endif
static boolean_t e1000_clean_tx_irq(struct e1000_adapter *adapter,
struct e1000_tx_ring *tx_ring);
#ifdef CONFIG_E1000_NAPI
@@ -300,31 +298,26 @@ module_exit(e1000_exit_module);
static int e1000_request_irq(struct e1000_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
- int flags, err = 0;
+ void (*handler) = &e1000_intr;
+ int irq_flags = IRQF_SHARED;
+ int err;
- flags = IRQF_SHARED;
-#ifdef CONFIG_PCI_MSI
if (adapter->hw.mac_type >= e1000_82571) {
- adapter->have_msi = TRUE;
- if ((err = pci_enable_msi(adapter->pdev))) {
- DPRINTK(PROBE, ERR,
-"Unable to allocate MSI interrupt Error: %d\n", err);
- adapter->have_msi = FALSE;
+ adapter->have_msi = !pci_enable_msi(adapter->pdev);
+ if (adapter->have_msi) {
+ handler = &e1000_intr_msi;
+ irq_flags = 0;
}
}
- if (adapter->have_msi) {
- flags &= ~IRQF_SHARED;
- err = request_irq(adapter->pdev->irq, &e1000_intr_msi, flags,
- netdev->name, netdev);
- if (err)
- DPRINTK(PROBE, ERR,
- "Unable to allocate interrupt Error: %d\n", err);
- } else
-#endif
- if ((err = request_irq(adapter->pdev->irq, &e1000_intr, flags,
- netdev->name, netdev)))
+
+ err = request_irq(adapter->pdev->irq, handler, irq_flags, netdev->name,
+ netdev);
+ if (err) {
+ if (adapter->have_msi)
+ pci_disable_msi(adapter->pdev);
DPRINTK(PROBE, ERR,
"Unable to allocate interrupt Error: %d\n", err);
+ }
return err;
}
@@ -335,10 +328,8 @@ static void e1000_free_irq(struct e1000_adapter *adapter)
free_irq(adapter->pdev->irq, netdev);
-#ifdef CONFIG_PCI_MSI
if (adapter->have_msi)
pci_disable_msi(adapter->pdev);
-#endif
}
/**
@@ -3744,7 +3735,6 @@ e1000_update_stats(struct e1000_adapter *adapter)
spin_unlock_irqrestore(&adapter->stats_lock, flags);
}
-#ifdef CONFIG_PCI_MSI
/**
* e1000_intr_msi - Interrupt Handler
@@ -3810,7 +3800,6 @@ e1000_intr_msi(int irq, void *data)
return IRQ_HANDLED;
}
-#endif
/**
* e1000_intr - Interrupt Handler
-
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] e1000: Work around 82571 completion timout on Pseries HW
Our 82571 (first PCI-E hardware) causes P-Series hardware to throw
issues. Disabling PCI-E completion timeouts in our NIC resolves
the issue.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Cc: Wen Xiong <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 49be393..830d851 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -819,6 +819,16 @@ e1000_reset(struct e1000_adapter *adapter)
E1000_WRITE_REG(&adapter->hw, CTRL, ctrl);
}
+#if defined(CONFIG_PPC64) || defined(CONFIG_PPC)
+#define E1000_GCR_DISABLE_TIMEOUT_MECHANISM 0x8000
+ if (adapter->hw.mac.type == e1000_82571) {
+ /* work around pSeries hardware by disabling timeouts */
+ u32 gcr = E1000_READ_REG(&adapter->hw, E1000_GCR);
+ gcr |= E1000_GCR_DISABLE_TIMEOUT_MECHANISM;
+ E1000_WRITE_REG(&adapter->hw, E1000_GCR, gcr);
+ }
+#endif
+
/* Enable h/w to recognize an 802.1Q VLAN Ethernet packet */
E1000_WRITE_REG(&adapter->hw, VET, ETHERNET_IEEE_VLAN_TYPE);
-
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] e1000: Work around 82571 completion timout on Pseries HW
Auke Kok wrote:
Our 82571 (first PCI-E hardware) causes P-Series hardware to throw
issues. Disabling PCI-E completion timeouts in our NIC resolves
the issue.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Cc: Wen Xiong <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 49be393..830d851 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -819,6 +819,16 @@ e1000_reset(struct e1000_adapter *adapter)
E1000_WRITE_REG(&adapter->hw, CTRL, ctrl);
}
+#if defined(CONFIG_PPC64) || defined(CONFIG_PPC)
+#define E1000_GCR_DISABLE_TIMEOUT_MECHANISM 0x8000
+ if (adapter->hw.mac.type == e1000_82571) {
+ /* work around pSeries hardware by disabling timeouts */
+ u32 gcr = E1000_READ_REG(&adapter->hw, E1000_GCR);
+ gcr |= E1000_GCR_DISABLE_TIMEOUT_MECHANISM;
+ E1000_WRITE_REG(&adapter->hw, E1000_GCR, gcr);
Why is this needed?
Is pSeries PCI-E implementation problematic? Or is this a e1000 PCI-E
hardware bug? If the former, I wonder if this is the best way to work
around the issue, especially since it might crop up in other PCI-E
boards besides e1000. If the latter, it seems like we should disable
the feature on all platforms.
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/7] CAN: Add PF_CAN core module
On 5/16/07, Urs Thuermann <[EMAIL PROTECTED]> wrote:
This patch adds the CAN core functionality but no protocols or drivers.
No protocol implementations are included here. They come as separate
patches. Protocol numbers are already in include/linux/can.h.
Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]>
+
+/**
+ * struct sockaddr_can - the sockaddr structure for CAN sockets
+ * @can_family: address family number AF_CAN.
+ * @can_ifindex: CAN network interface index.
+ * @can_addr:transport protocol specific address, mostly CAN IDs.
+ */
+struct sockaddr_can {
+ sa_family_t can_family;
+ int can_ifindex;
+ union {
+ struct { canid_t rx_id, tx_id; } tp16;
+ struct { canid_t rx_id, tx_id; } tp20;
+ struct { canid_t rx_id, tx_id; } mcnet;
+ struct { canid_t rx_id, tx_id; } isotp;
+ struct { int lcu, type; } bap;
+ } can_addr;
+};
Can can_ifindex be turned into a unsigned short? That way we would
have it nicely packed, avoiding this hole:
[EMAIL PROTECTED] examples]$ pahole can
/* <1c2> /home/acme/git/pahole/examples/can.c:5 */
struct sockaddr_can {
sa_family_tcan_family;/* 0 2 */
/* XXX 2 bytes hole, try to pack */
intcan_ifindex; /* 4 4 */
union {
struct {
canid_trx_id; /* 8 4 */
canid_ttx_id; /* 12 4 */
} tp16; /* 8 */
struct {
canid_trx_id; /* 8 4 */
canid_ttx_id; /* 12 4 */
} tp20; /* 8 */
struct {
canid_trx_id; /* 8 4 */
canid_ttx_id; /* 12 4 */
} mcnet; /* 8 */
struct {
canid_trx_id; /* 8 4 */
canid_ttx_id; /* 12 4 */
} isotp; /* 8 */
struct {
intlcu; /* 8 4 */
inttype; /* 12 4 */
} bap;/* 8 */
} can_addr; /* 8 8 */
}; /* size: 16, cachelines: 1 */
/* sum members: 14, holes: 1, sum holes: 2 */
/* last cacheline: 16 bytes */
/* definitions: 1 */
- Arnaldo
-
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] PCI legacy I/O port free driver - Making Intel e1000 driver legacy I/O port free
Kok, Auke wrote:
Tomohiro Kusumi wrote:
Dear Auke
> I'm ok with the bottom part of the patch, but I do not like
> the modification of the pci device ID table in this way. As
> Arjan van der Ven previously commented as well, this makes
> it hard for future device ID's to be bound to the driver.
I googled the previous comment by Arjan. Now I understand
that the patch makes it difficult to add PCI ID's to the
driver at runtime.
> On top of that, there is no logical correlation between the
> mapping and chipsets, so a lot of information is lost in that
> table. It really does not show which _chipsets_ support this
> functionality.
Thanks for pointing out the problem, but I can't quite understand
what you are trying to say. What do you mean by the chipset?
Are you talking about the chipset of the NIC? or the South bridge?
I'd be glad if you can explain it to me.
perhaps my wording was poor. I was referring to the NIC chip. Since there are
about 12 different physical e1000 NIC chips (and lots of different pci IDs per
e1000 NIC chip), it would be best to correlate the capability of each NIC chip
number to be able to work without legacy IO mode instead of providing this
mapping based on the PCI device ID.
It would serve two purposes: new pci id's for a chipset of which we already know
that it can work without legacy IO can automatically inherit this property from
the NIC chipset properties, and new e1000 chips would automatically get a
default property for this value.
I will (time permitting) try to reverse your matrix to chip numbers and see if
we can add this property in a much easier way.
Okay, you appear to enable io for the following chipsets:
82540 chips:
82540EM
82540EM_LOM
82540EP
82540EP_LOM
82540EP_LP
those are all the 82540's, OK
82541 chips:
82541EI
82541EI_MOBILE
82541ER
82541ER_LOM
82541GI
82541GI_LF
82541GI_MOBILE
Those are all the 82541's, OK too
82544 chips:
82544EI_COPPER
82544EI_FIBER
82544GC_COPPER
82544GC_LOM
Those are all the 82543's, OK too
82545's:
82545EM_COPPER
82545EM_FIBER
Here you skip 3 other 82545 device ID's, was that intentional?
82546's:
82546EB_COPPER
82546EB_FIBER
82546EB_QUAD_COPPER
Here you skip over 9 82546 device ID's... same question.
It appears that probably the 82543's would also work under ioport, 82547 might
be the odd one out that might work without IOport. I think 82542 definately
needs it...
can you tell me how you created the initial list?
Summarizing, it appears that we should condense the list to: (sketch)
switch (adapter->hw.mac.type) {
case e1000_82542 ... e1000_82541_rev_2:
adapter->ioport_capable = 1;
break;
default:
break;
}
I also would like this option to be non-default, IOW use legacy IO by default,
and allow the user to specify a module load option to disable use of this feature:
static unsigned int use_ioport = 1;
module_param(use_ioport, uint, 0644);
MODULE_PARM_DESC(use_ioport, "Use Legacy IO port mapping (default: 1)");
or something like this to allow the feature to be tested before we turn legacy
ioport off for all adapters and everyone.
Do you think you can accomodate these changes?
Cheers,
Auke
Auke
Tomohiro Kusumi
Kok, Auke wrote:
Tomohiro Kusumi wrote:
Hi
As you can see in the "10. pci_enable_device_bars() and Legacy I/O
Port space" of the Documentation/pci.txt, the latest kernel has
interfaces for PCI device drivers to tell the kernel which resource
the driver want to use, ex. I/O port or MMIO.
I've made a patch which makes Intel e1000 driver legacy I/O port
free by using the PCI core changes I mentioned above. The Intel
e1000 driver can handle some of its devices without using I/O port.
So this patch changes the driver not to enable/request I/O port
region depending on the device id.
As a result, the driver can handle its device even when there are
huge number of PCI devices being used on the system and no I/O
port region assigned to the device.
Tomohiro,
I'm ok with the bottom part of the patch, but I do not like the
modification of the pci device ID table in this way. As Arjan van der
Ven previously commented as well, this makes it hard for future device
ID's to be bound to the driver.
On top of that, there is no logical correlation between the mapping and
chipsets, so a lot of information is lost in that table. It really does
not show which _chipsets_ support this functionality.
I think if we want to work with this, we need some way of mapping the
device ID's back to chipsets, and enable the feature on that basis.
Auke
Tomohiro Kusumi
Signed-off-by: Tomohiro Kusumi <[EMAIL PROTECTED]>
---
e1000.h |6 +-
e1000_main.c | 152
+++
2 files changed, 86 insertions(+), 72 deletions(-)
diff -uprN linux-2.6.21.orig/drivers/net/e1000/e1000.h
linux-2.6.21/drivers/net/e1000/e1000.h
--- linux-2.6.21.orig/drivers/net/e1000/e1000.h2007-0
Re: [PATCH] ibm_emac: Correctly detect old link speed
On Wed, May 16, 2007 at 01:00:08PM +0200, Stefan Roese wrote: > This patch fixes a bug where the link speed change was not > detected correctly. This occured on a 440SPe (EMAC4) system > where the old link speed was 100Mbps and the new link speed > is 1000Mbps. Good catch, Stefan. Unfortunately, I have to NACK your patch - you broke non EMAC4 builds. Correct fix is just to remove EMAC_MR1_MF_1000GPCS from the first if condition. I'll send correct fix shortly along with other queued patches. -- Eugene - 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: Re: [patch 2/7] CAN: Add PF_CAN core module
Arnaldo Carvalho de Melo wrote:
> +
> +/**
> + * struct sockaddr_can - the sockaddr structure for CAN sockets
> + * @can_family: address family number AF_CAN.
> + * @can_ifindex: CAN network interface index.
> + * @can_addr:transport protocol specific address, mostly CAN IDs.
> + */
> +struct sockaddr_can {
> + sa_family_t can_family;
> + int can_ifindex;
> + union {
> + struct { canid_t rx_id, tx_id; } tp16;
> + struct { canid_t rx_id, tx_id; } tp20;
> + struct { canid_t rx_id, tx_id; } mcnet;
> + struct { canid_t rx_id, tx_id; } isotp;
> + struct { int lcu, type; } bap;
> + } can_addr;
> +};
Can can_ifindex be turned into a unsigned short?
Hm - did you ever search for ifindex in the kernel?
E.g. in struct net_device in include/linux/netdevice.h , or functions
like dev_get_by_index() ?
The interface index (ifindex) is always(!) defined as an integer.
I think, we would get rightly knocked defining ifindex as a short value ;-)
Regards,
Oliver
-
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] e1000: Fix msi enable leak on error, don't print error message, cleanup
Some more of my paranoid questions :) So, if a driver tries to enable MSI and that is unsuccessful (I'll try to avoid using the possibly loaded term "fails") shouldn't that show-up _somewhere_? Just how "normal" is an attempt to enable MSI not succeding going to remain over time and aren't there times when it does indeed mean that someone should be looking into it? rick jones - 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] ibm_emac: Correctly detect old link speed
On Wednesday 16 May 2007, Eugene Surovegin wrote: > On Wed, May 16, 2007 at 01:00:08PM +0200, Stefan Roese wrote: > > This patch fixes a bug where the link speed change was not > > detected correctly. This occured on a 440SPe (EMAC4) system > > where the old link speed was 100Mbps and the new link speed > > is 1000Mbps. > > Good catch, Stefan. Unfortunately, I have to NACK your patch - you > broke non EMAC4 builds. Yes, you're right of course. > Correct fix is just to remove EMAC_MR1_MF_1000GPCS from the first > if condition. Yep. > I'll send correct fix shortly along with other queued patches. Thanks. Best regards, Stefan - 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] ibm_emac: fix section mismatch warnings
Fix "Section mismatch" warnings
Signed-off-by: Eugene Surovegin <[EMAIL PROTECTED]>
---
drivers/net/ibm_emac/ibm_emac_mal.c |3 +--
drivers/net/ibm_emac/ibm_emac_mal.h |3 +--
drivers/net/ibm_emac/ibm_emac_rgmii.c |2 +-
drivers/net/ibm_emac/ibm_emac_rgmii.h |2 +-
drivers/net/ibm_emac/ibm_emac_tah.c |2 +-
drivers/net/ibm_emac/ibm_emac_tah.h |2 +-
drivers/net/ibm_emac/ibm_emac_zmii.c |2 +-
drivers/net/ibm_emac/ibm_emac_zmii.h |2 +-
8 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.c
b/drivers/net/ibm_emac/ibm_emac_mal.c
index 6c0f071..cabd984 100644
--- a/drivers/net/ibm_emac/ibm_emac_mal.c
+++ b/drivers/net/ibm_emac/ibm_emac_mal.c
@@ -59,8 +59,7 @@ int __init mal_register_commac(struct ibm_ocp_mal *mal,
return 0;
}
-void __exit mal_unregister_commac(struct ibm_ocp_mal *mal,
- struct mal_commac *commac)
+void mal_unregister_commac(struct ibm_ocp_mal *mal, struct mal_commac *commac)
{
unsigned long flags;
local_irq_save(flags);
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h
b/drivers/net/ibm_emac/ibm_emac_mal.h
index 407d2ac..64bc338 100644
--- a/drivers/net/ibm_emac/ibm_emac_mal.h
+++ b/drivers/net/ibm_emac/ibm_emac_mal.h
@@ -223,8 +223,7 @@ void mal_exit(void) __exit;
int mal_register_commac(struct ibm_ocp_mal *mal,
struct mal_commac *commac) __init;
-void mal_unregister_commac(struct ibm_ocp_mal *mal,
- struct mal_commac *commac) __exit;
+void mal_unregister_commac(struct ibm_ocp_mal *mal, struct mal_commac *commac);
int mal_set_rcbs(struct ibm_ocp_mal *mal, int channel, unsigned long size);
/* Returns BD ring offset for a particular channel
diff --git a/drivers/net/ibm_emac/ibm_emac_rgmii.c
b/drivers/net/ibm_emac/ibm_emac_rgmii.c
index 53d281c..9dbb5e5 100644
--- a/drivers/net/ibm_emac/ibm_emac_rgmii.c
+++ b/drivers/net/ibm_emac/ibm_emac_rgmii.c
@@ -162,7 +162,7 @@ void rgmii_set_speed(struct ocp_device *ocpdev, int input,
int speed)
out_be32(&dev->base->ssr, ssr);
}
-void __exit __rgmii_fini(struct ocp_device *ocpdev, int input)
+void __rgmii_fini(struct ocp_device *ocpdev, int input)
{
struct ibm_ocp_rgmii *dev = ocp_get_drvdata(ocpdev);
BUG_ON(!dev || dev->users == 0);
diff --git a/drivers/net/ibm_emac/ibm_emac_rgmii.h
b/drivers/net/ibm_emac/ibm_emac_rgmii.h
index 117ea48..971e458 100644
--- a/drivers/net/ibm_emac/ibm_emac_rgmii.h
+++ b/drivers/net/ibm_emac/ibm_emac_rgmii.h
@@ -37,7 +37,7 @@ struct ibm_ocp_rgmii {
#ifdef CONFIG_IBM_EMAC_RGMII
int rgmii_attach(void *emac) __init;
-void __rgmii_fini(struct ocp_device *ocpdev, int input) __exit;
+void __rgmii_fini(struct ocp_device *ocpdev, int input);
static inline void rgmii_fini(struct ocp_device *ocpdev, int input)
{
if (ocpdev)
diff --git a/drivers/net/ibm_emac/ibm_emac_tah.c
b/drivers/net/ibm_emac/ibm_emac_tah.c
index e287b45..3c2d5ba 100644
--- a/drivers/net/ibm_emac/ibm_emac_tah.c
+++ b/drivers/net/ibm_emac/ibm_emac_tah.c
@@ -63,7 +63,7 @@ int __init tah_attach(void *emac)
return 0;
}
-void __exit __tah_fini(struct ocp_device *ocpdev)
+void __tah_fini(struct ocp_device *ocpdev)
{
struct tah_regs *p = ocp_get_drvdata(ocpdev);
BUG_ON(!p);
diff --git a/drivers/net/ibm_emac/ibm_emac_tah.h
b/drivers/net/ibm_emac/ibm_emac_tah.h
index 3815394..ccf6491 100644
--- a/drivers/net/ibm_emac/ibm_emac_tah.h
+++ b/drivers/net/ibm_emac/ibm_emac_tah.h
@@ -55,7 +55,7 @@ struct tah_regs {
#ifdef CONFIG_IBM_EMAC_TAH
int tah_attach(void *emac) __init;
-void __tah_fini(struct ocp_device *ocpdev) __exit;
+void __tah_fini(struct ocp_device *ocpdev);
static inline void tah_fini(struct ocp_device *ocpdev)
{
if (ocpdev)
diff --git a/drivers/net/ibm_emac/ibm_emac_zmii.c
b/drivers/net/ibm_emac/ibm_emac_zmii.c
index 37dc8f3..2c0fdb0 100644
--- a/drivers/net/ibm_emac/ibm_emac_zmii.c
+++ b/drivers/net/ibm_emac/ibm_emac_zmii.c
@@ -215,7 +215,7 @@ void __zmii_set_speed(struct ocp_device *ocpdev, int input,
int speed)
out_be32(&dev->base->ssr, ssr);
}
-void __exit __zmii_fini(struct ocp_device *ocpdev, int input)
+void __zmii_fini(struct ocp_device *ocpdev, int input)
{
struct ibm_ocp_zmii *dev = ocp_get_drvdata(ocpdev);
BUG_ON(!dev || dev->users == 0);
diff --git a/drivers/net/ibm_emac/ibm_emac_zmii.h
b/drivers/net/ibm_emac/ibm_emac_zmii.h
index 972e3a4..fad6d8b 100644
--- a/drivers/net/ibm_emac/ibm_emac_zmii.h
+++ b/drivers/net/ibm_emac/ibm_emac_zmii.h
@@ -40,7 +40,7 @@ struct ibm_ocp_zmii {
#ifdef CONFIG_IBM_EMAC_ZMII
int zmii_attach(void *emac) __init;
-void __zmii_fini(struct ocp_device *ocpdev, int input) __exit;
+void __zmii_fini(struct ocp_device *ocpdev, int input);
static inline void zmii_fini(struct ocp_device *ocpdev, int input)
{
if (ocpdev)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of
[PATCH 2/3] ibm_emac: improved PHY support
Original patch is from Jeff Haran <[EMAIL PROTECTED]> with my minor style
fixes. His comments follow:
The first problem was in the function that configures the PHY for
autonegotiation, genmii_setup_aneg(). The original code does a
read/modify/write of the autonegotiation advertizement register (reg 4),
followed by a read/modify/write of the control register (reg 0). While
the original code follows the proper procedure as per reading the IEEE
specs, what I found is that on at least one PHY model (National DP83843)
the read of the control register comes back with the soft reset bit set
(bit 15). Because of the read/modify/write operation, this causes the
write to write a 1 back to the reset bit, which initiates a software
reset of the PHY. This software reset causes the PHY to return to its
power up state which advertizes all modes of operation, thus negating
the write to the autoneg advertizement register. The modification is to
spin reading the control register until the soft reset bit is clear
before doing the modify/write.
The second problem was in the function that configures the PHY for
forced operation, genmii_setup_forced(). The original code initiates a
software reset operation via a write of a 1 to bit 15 of the control
register (reg 0), but then proceeds to do a second write to that same
register without waiting until that reset bit is cleared by the PHY
itself (which according to the IEEE specs indicates that the PHY reset
is complete). This is a violation of how one is supposed to use this
software reset feature of these PHYs and I believe was the cause of
mysterious, difficult to reproduce link failures that we've observed on
some of our systems that use this driver. The fix is to modify the
function so that it spins waiting for the reset bit to clear after doing
the soft reset and before doing the subsequent write.
Signed-off-by: Jeff Haran <[EMAIL PROTECTED]>
CC: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Eugene Surovegin <[EMAIL PROTECTED]>
---
drivers/net/ibm_emac/ibm_emac_phy.c | 60 ++-
1 files changed, 45 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_phy.c
b/drivers/net/ibm_emac/ibm_emac_phy.c
index 9074f76..e57862b 100644
--- a/drivers/net/ibm_emac/ibm_emac_phy.c
+++ b/drivers/net/ibm_emac/ibm_emac_phy.c
@@ -22,6 +22,7 @@
#include
+#include "ibm_emac_core.h"
#include "ibm_emac_phy.h"
static inline int phy_read(struct mii_phy *phy, int reg)
@@ -34,11 +35,39 @@ static inline void phy_write(struct mii_phy *phy, int reg,
int val)
phy->mdio_write(phy->dev, phy->address, reg, val);
}
-int mii_reset_phy(struct mii_phy *phy)
+/*
+ * polls MII_BMCR until BMCR_RESET bit clears or operation times out.
+ *
+ * returns:
+ * >= 0 => success, value in BMCR returned to caller
+ * -EBUSY => failure, RESET bit never cleared
+ * otherwise => failure, lower level PHY read failed
+ */
+static int mii_spin_reset_complete(struct mii_phy *phy)
{
int val;
int limit = 1;
+ while (limit--) {
+ val = phy_read(phy, MII_BMCR);
+ if (val >= 0 && !(val & BMCR_RESET))
+ return val; /* success */
+ udelay(10);
+ }
+ if (val & BMCR_RESET)
+ val = -EBUSY;
+
+ if (net_ratelimit())
+ printk(KERN_ERR "emac%d: PHY reset timeout (%d)\n",
+ ((struct ocp_enet_private *)phy->dev->priv)->def->index,
+ val);
+ return val;
+}
+
+int mii_reset_phy(struct mii_phy *phy)
+{
+ int val;
+
val = phy_read(phy, MII_BMCR);
val &= ~BMCR_ISOLATE;
val |= BMCR_RESET;
@@ -46,16 +75,11 @@ int mii_reset_phy(struct mii_phy *phy)
udelay(300);
- while (limit--) {
- val = phy_read(phy, MII_BMCR);
- if (val >= 0 && (val & BMCR_RESET) == 0)
- break;
- udelay(10);
- }
- if ((val & BMCR_ISOLATE) && limit > 0)
+ val = mii_spin_reset_complete(phy);
+ if (val >= 0 && (val & BMCR_ISOLATE))
phy_write(phy, MII_BMCR, val & ~BMCR_ISOLATE);
- return limit <= 0;
+ return val < 0;
}
static int genmii_setup_aneg(struct mii_phy *phy, u32 advertise)
@@ -102,8 +126,14 @@ static int genmii_setup_aneg(struct mii_phy *phy, u32
advertise)
}
/* Start/Restart aneg */
- ctl = phy_read(phy, MII_BMCR);
- ctl |= (BMCR_ANENABLE | BMCR_ANRESTART);
+ /* on some PHYs (e.g. National DP83843) a write to MII_ADVERTISE
+* causes BMCR_RESET to be set on the next read of MII_BMCR, which
+* if not checked for causes the PHY to be reset below */
+ ctl = mii_spin_reset_complete(phy);
+ if (ctl < 0)
+ return ctl;
+
+ ctl |= BMCR_ANENABLE | BMCR_ANRESTART;
phy_write(phy, MII_BMCR, ctl);
return 0;
@@ -118,13
[PATCH 3/3] ibm_emac: fix link speed detection change
Fix link speed detection change. Thanks to Stefan Roese <[EMAIL PROTECTED]> for finding this bug. CC: Stefan Roese <[EMAIL PROTECTED]> Signed-off-by: Eugene Surovegin <[EMAIL PROTECTED]> --- drivers/net/ibm_emac/ibm_emac_core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c index 50035eb..f752e5f 100644 --- a/drivers/net/ibm_emac/ibm_emac_core.c +++ b/drivers/net/ibm_emac/ibm_emac_core.c @@ -926,7 +926,7 @@ static int emac_link_differs(struct ocp_enet_private *dev) int duplex = r & EMAC_MR1_FDE ? DUPLEX_FULL : DUPLEX_HALF; int speed, pause, asym_pause; - if (r & (EMAC_MR1_MF_1000 | EMAC_MR1_MF_1000GPCS)) + if (r & EMAC_MR1_MF_1000) speed = SPEED_1000; else if (r & EMAC_MR1_MF_100) speed = SPEED_100; - 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] e1000: Fix msi enable leak on error, don't print error message, cleanup
Rick Jones wrote: > Some more of my paranoid questions :) > > So, if a driver tries to enable MSI and that is unsuccessful (I'll try > to avoid using the possibly loaded term "fails") shouldn't that show-up > _somewhere_? It already does -- in /proc/interrupts. > Just how "normal" is an attempt to enable MSI not succeding > going to remain over time and aren't there times when it does indeed > mean that someone should be looking into it? If we ever want a message, that should go in the general code and not in each driver. -hpa - 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] e1000: Fix msi enable leak on error, don't print error message, cleanup
Rick Jones wrote: So, if a driver tries to enable MSI and that is unsuccessful (I'll try to avoid using the possibly loaded term "fails") shouldn't that show-up _somewhere_? Just how "normal" is an attempt to enable MSI not succeding going to remain over time and aren't there times when it does indeed mean that someone should be looking into it? If there is an MSI problem, it is the job of the PCI core to complain. 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] e1000: Fix msi enable leak on error, don't print error message, cleanup
H. Peter Anvin wrote: Rick Jones wrote: Some more of my paranoid questions :) So, if a driver tries to enable MSI and that is unsuccessful (I'll try to avoid using the possibly loaded term "fails") shouldn't that show-up _somewhere_? It already does -- in /proc/interrupts. But that is rather incidental isn't it? Would some sort of system health monitor be likely to be checking that for interrupt flavors? And just looking at /proc/interrupts, while it tells you what sort of interrupt is being used, it doesn't (IIRC) say anything about what sort of interrupt the driver _tried_ to use. rick jones - 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/7] CAN: Add PF_CAN core module
"Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]> writes: > Can can_ifindex be turned into a unsigned short? That way we would > have it nicely packed, avoiding this hole: Since dev->ifindex is int and we have many assignments between can_ifindex and dev->ifindex it would not make sense to define can_ifindex as a short int. Also in user space, ifindex is int, e.g. in struct ifreq. This would cause implicit truncating type casts from int to short int (some compilers warn about this, haven't tried GCC for a long time) or require many explicit type casts. urs - 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] e1000: Fix msi enable leak on error, don't print error message, cleanup
Rick Jones wrote: But that is rather incidental isn't it? Would some sort of system health monitor be likely to be checking that for interrupt flavors? And Well, that's where the information is exported in a standard way. I hope you're not suggesting that a system health monitor should be parsing random, driver-specific printk messages to obtain the same information? just looking at /proc/interrupts, while it tells you what sort of interrupt is being used, it doesn't (IIRC) say anything about what sort of interrupt the driver _tried_ to use. True. In the context of this thread, it could be any number of reasons: MSI isn't compiled in. MSI was disabled at runtime via kernel command line. MSI was disabled by BIOS quirk. MSI enable was attempted, but failed for some reason. None of those reasons are really driver-specific, or need driver-specific complaint messages. 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] e1000: Fix msi enable leak on error, don't print error message, cleanup
From: Rick Jones <[EMAIL PROTECTED]> Date: Wed, 16 May 2007 11:41:15 -0700 > Some more of my paranoid questions :) > > So, if a driver tries to enable MSI and that is unsuccessful (I'll try to > avoid > using the possibly loaded term "fails") shouldn't that show-up _somewhere_? > Just how "normal" is an attempt to enable MSI not succeding going to remain > over > time and aren't there times when it does indeed mean that someone should be > looking into it? We have whole platforms where pci_enable_msi() is going to fail on every call, it doesn't help to mention this to be honest. - 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/2] ibmveth: Fix h_free_logical_lan error on pool resize
When attempting to activate additional rx buffer pools on an ibmveth interface
that
was not yet up, the error below was seen. The patch fixes this by only closing
and opening the interface to activate the resize if the interface is already
opened.
(drivers/net/ibmveth.c:597 ua:3004) ERROR: h_free_logical_lan failed with
fffc, continuing with close
Unable to handle kernel paging request for data at address 0x0ff8
Faulting instruction address: 0xd02540e0
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA PSERIES LPAR
Modules linked in: ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle ipta
ble_nat ip_nat iptable_filter ip6table_mangle ip_conntrack nfnetlink ip_tables i
p6table_filter ip6_tables x_tables ipv6 apparmor aamatch_pcre loop dm_mod ibmvet
h sg ibmvscsic sd_mod scsi_mod
NIP: D02540E0 LR: D02540D4 CTR: 801AF404
REGS: c0001cd27870 TRAP: 0300 Not tainted (2.6.16.46-0.4-ppc64)
MSR: 80009032 CR: 24242422 XER: 0007
DAR: 0FF8, DSISR: 4000
TASK = c0001ca7b4e0[1636] 'sh' THREAD: c0001cd24000 CPU: 0
GPR00: D02540D4 C0001CD27AF0 D0265650 C0001C936500
GPR04: 80009032 0007 0002C2EF
GPR08: C0652A10 C0652AE0
GPR12: 4000 C04A3300 100A
GPR16: 100B8808 100C0F60 10084878
GPR20: 100C0CB0 100AF498 0002
GPR24: 100BA488 C0001C936760 D0258DD0 C0001C936000
GPR28: C0001C936500 D0265180 C0001C936000
NIP [D02540E0] .ibmveth_close+0xc8/0xf4 [ibmveth]
LR [D02540D4] .ibmveth_close+0xbc/0xf4 [ibmveth]
Call Trace:
[C0001CD27AF0] [D02540D4] .ibmveth_close+0xbc/0xf4 [ibmveth]
(unreliable)
[C0001CD27B80] [D02545FC] .veth_pool_store+0xd0/0x260 [ibmveth]
[C0001CD27C40] [C012E0E8] .sysfs_write_file+0x118/0x198
[C0001CD27CF0] [C00CDAF0] .vfs_write+0x130/0x218
[C0001CD27D90] [C00CE52C] .sys_write+0x4c/0x8c
[C0001CD27E30] [C000871C] syscall_exit+0x0/0x40
Instruction dump:
419affd8 2fa3 419e0020 e93d e89e8040 38a00255 e87e81b0 80c90018
48001531 e8410028 e93d00e0 7fa3eb78 f81d0430 4bfffdc9 38210090
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 53 ++--
1 file changed, 31 insertions(+), 22 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_large_frames drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_large_frames2007-05-14
15:03:06.0 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-05-15 09:18:46.0
-0500
@@ -1243,16 +1243,19 @@ const char * buf, size_t count)
if (attr == &veth_active_attr) {
if (value && !pool->active) {
- if(ibmveth_alloc_buffer_pool(pool)) {
-ibmveth_error_printk("unable to alloc pool\n");
-return -ENOMEM;
-}
- pool->active = 1;
- adapter->pool_config = 1;
- ibmveth_close(netdev);
- adapter->pool_config = 0;
- if ((rc = ibmveth_open(netdev)))
- return rc;
+ if (netif_running(netdev)) {
+ if(ibmveth_alloc_buffer_pool(pool)) {
+ ibmveth_error_printk("unable to alloc
pool\n");
+ return -ENOMEM;
+ }
+ pool->active = 1;
+ adapter->pool_config = 1;
+ ibmveth_close(netdev);
+ adapter->pool_config = 0;
+ if ((rc = ibmveth_open(netdev)))
+ return rc;
+ } else
+ pool->active = 1;
} else if (!value && pool->active) {
int mtu = netdev->mtu + IBMVETH_BUFF_OH;
int i;
@@ -1281,23 +1284,29 @@ const char * buf, size_t count)
if (value <= 0 || value > IBMVETH_MAX_POOL_COUNT)
return -EINVAL;
else {
- adapter->pool_config = 1;
- ibmveth_close(netdev);
- adapter->pool_config = 0;
- pool->size = value;
- if ((rc = ibmveth_open(netdev)))
- return rc;
+ if (netif_running(netdev)) {
+ adapter->pool_config =
[PATCH 2/2] ibmveth: Automatically enable larger rx buffer pools for larger mtu
Currently, ibmveth maintains several rx buffer pools, which can
be modified through sysfs. By default, pools are not allocated by
default such that jumbo frames cannot be supported without first
activating larger rx buffer pools. This results in failures when attempting
to change the mtu. This patch makes ibmveth automatically allocate
these larger buffer pools when the mtu is changed.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_large_mtu drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_large_mtu 2007-05-16
10:47:54.0 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-05-16 10:47:54.0
-0500
@@ -915,17 +915,36 @@ static int ibmveth_change_mtu(struct net
{
struct ibmveth_adapter *adapter = dev->priv;
int new_mtu_oh = new_mtu + IBMVETH_BUFF_OH;
- int i;
+ int reinit = 0;
+ int i, rc;
if (new_mtu < IBMVETH_MAX_MTU)
return -EINVAL;
+ for (i = 0; i < IbmVethNumBufferPools; i++)
+ if (new_mtu_oh < adapter->rx_buff_pool[i].buff_size)
+ break;
+
+ if (i == IbmVethNumBufferPools)
+ return -EINVAL;
+
/* Look for an active buffer pool that can hold the new MTU */
for(i = 0; irx_buff_pool[i].active)
- continue;
+ if (!adapter->rx_buff_pool[i].active) {
+ adapter->rx_buff_pool[i].active = 1;
+ reinit = 1;
+ }
+
if (new_mtu_oh < adapter->rx_buff_pool[i].buff_size) {
- dev->mtu = new_mtu;
+ if (reinit && netif_running(adapter->netdev)) {
+ adapter->pool_config = 1;
+ ibmveth_close(adapter->netdev);
+ adapter->pool_config = 0;
+ dev->mtu = new_mtu;
+ if ((rc = ibmveth_open(adapter->netdev)))
+ return rc;
+ } else
+ dev->mtu = new_mtu;
return 0;
}
}
_
-
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] e1000: Fix msi enable leak on error, don't print error message, cleanup
Jeff Garzik wrote: Rick Jones wrote: But that is rather incidental isn't it? Would some sort of system health monitor be likely to be checking that for interrupt flavors? And Well, that's where the information is exported in a standard way. I hope you're not suggesting that a system health monitor should be parsing random, driver-specific printk messages to obtain the same information? No, I wouldn't. The only "system health monitor" I would expect to be parsing that sort of thing would be a human. Perhaps I'm just backing-into the meta question via the specifics of this driver patch. just looking at /proc/interrupts, while it tells you what sort of interrupt is being used, it doesn't (IIRC) say anything about what sort of interrupt the driver _tried_ to use. True. In the context of this thread, it could be any number of reasons: MSI isn't compiled in. MSI was disabled at runtime via kernel command line. MSI was disabled by BIOS quirk. MSI enable was attempted, but failed for some reason. None of those reasons are really driver-specific, or need driver-specific complaint messages. Agreed. But is the PCI (?) subsystem doing something in that regard or is this a hole? rick jones - 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] gianfar: Add I/O barriers when touching buffer descriptor ownership.
The hardware must not see that is given ownership of a buffer until it is
completely written, and when the driver receives ownership of a buffer,
it must ensure that any other reads to the buffer reflect its final
state. Thus, I/O barriers are added where required.
Without this patch, I have observed GCC reordering the setting of
bdp->length and bdp->status in gfar_new_skb. Hardware reordering
was also theoretically possible.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
I've added the requested comments to the source code about
the use of eieio(). Jeff, please consider for 2.6.22, as it
fixes a bug that has been observed.
drivers/net/gianfar.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index b666a0c..f5b3cba 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1025,6 +1025,15 @@ static int gfar_start_xmit(struct sk_buff *skb, struct
net_device *dev)
dev->trans_start = jiffies;
+ /* The powerpc-specific eieio() is used, as wmb() has too strong
+* semantics (it requires synchronization between cacheable and
+* uncacheable mappings, which eieio doesn't provide and which we
+* don't need), thus requiring a more expensive sync instruction. At
+* some point, the set of architecture-independent barrier functions
+* should be expanded to include weaker barriers.
+*/
+
+ eieio();
txbdp->status = status;
/* If this was the last BD in the ring, the next one */
@@ -1301,6 +1310,7 @@ struct sk_buff * gfar_new_skb(struct net_device *dev,
struct rxbd8 *bdp)
bdp->length = 0;
/* Mark the buffer empty */
+ eieio();
bdp->status |= (RXBD_EMPTY | RXBD_INTERRUPT);
return skb;
@@ -1484,6 +1494,7 @@ int gfar_clean_rx_ring(struct net_device *dev, int
rx_work_limit)
bdp = priv->cur_rx;
while (!((bdp->status & RXBD_EMPTY) || (--rx_work_limit < 0))) {
+ rmb();
skb = priv->rx_skbuff[priv->skb_currx];
if (!(bdp->status &
--
1.5.0.3
-
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: [3/3] 2.6.22-rc1: known regressions v2
Hi all, Here is a list of some known regressions in 2.6.22-rc1. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Timers/NOHZ Subject: 2.6.21-git4 BUG: soft lockup detected on CPU#1! References : http://lkml.org/lkml/2007/5/2/511 Submitter : Michal Piotrowski <[EMAIL PROTECTED]> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> Status : problem is being debugged USB Subject: usb hotplug/udev cannot correctly register usb/scanners References : http://lkml.org/lkml/2007/5/15/205 Submitter : [EMAIL PROTECTED] <[EMAIL PROTECTED]> Status : Unknown V4L Subject: V4L ABI breakage References : http://lkml.org/lkml/2007/5/14/42 Submitter : Robert Fitzsimons <[EMAIL PROTECTED]> Caused-By : Hans Verkuil <[EMAIL PROTECTED]> Mauro Carvalho Chehab <[EMAIL PROTECTED]> commit 206ebaf32795cf1582b1e2ff2ec6a560c9e986b8 Status : Unknown Networking Subject: panic with e1000 driver on HP Integrity servers References : http://bugzilla.kernel.org/show_bug.cgi?id=8455 Submitter : Doug Chapman <[EMAIL PROTECTED]> Caused-By : Auke Kok <[EMAIL PROTECTED]> commit e0aac5a289b1dacbc94bd9ae8c449bcdf9ab508c Status : problem is being debugged Regards, Michal -- Michal K. K. Piotrowski Kernel Monkeys (http://kernel.wikidot.com/start) - 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: [3/3] 2.6.22-rc1: known regressions v2
Hi Michal, V4L Subject: V4L ABI breakage References : http://lkml.org/lkml/2007/5/14/42 Submitter : Robert Fitzsimons <[EMAIL PROTECTED]> Caused-By : Hans Verkuil <[EMAIL PROTECTED]> Mauro Carvalho Chehab <[EMAIL PROTECTED]> commit 206ebaf32795cf1582b1e2ff2ec6a560c9e986b8 Status : Unknown We are currently working on it. I expect to have a patch fixing the issue until next week. Cheers, Mauro. - 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
Oops in netxen driver, kernel 2.6.20.10
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240190
drivers/net/netxen/netxen_nic_init.c:
if (ADDR_IN_WINDOW1(off)) {
writel(buf[i].data,
NETXEN_CRB_NORMALIZE(adapter, off));
} else {
netxen_nic_pci_change_crbwindow(adapter, 0);
Line 566 ==>writel(buf[i].data,
pci_base_offset(adapter, off));
netxen_nic_pci_change_crbwindow(adapter, 1);
}
pci_base_offset() returned NULL and the result was not checked, causing NULL
dereference.
offset is in RBX (== 0x000105ff) and is out of the expected range.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/40] mm: slab allocation fairness
On Fri, 4 May 2007, Peter Zijlstra wrote: > Page allocation rank is a scalar quantity connecting ALLOC_ and gfp flags > which > represents how deep we had to reach into our reserves when allocating a page. > Rank 0 is the deepest we can reach (ALLOC_NO_WATERMARK) and 16 is the most > shallow allocation possible (ALLOC_WMARK_HIGH). > > When the slab space is grown the rank of the page allocation is stored. For > each slab allocation we test the given gfp flags against this rank. Thereby > asking the question: would these flags have allowed the slab to grow. > > If not so, we need to test the current situation. This is done by forcing the > growth of the slab space. (Just testing the free page limits will not work due > to direct reclaim) Failing this we need to fail the slab allocation. This implies that an allocation at time t2 must be aware of the result of an allocation at time t1. It assumes a linear ordering of allocations that is not possible on large systems. Ordering of events is a very expensive endeavor in particular on NUMA systems given the potentially large latencies between various portions of the system. Maybe you need to restrict the ordering per cpu or per node? Per zone? Then we would need to store the ranks somewhere which raises scalability issues if these are global. - 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/7] CAN: Add PF_CAN core module
On 16 May 2007 21:14:20 +0200, Urs Thuermann <[EMAIL PROTECTED]> wrote: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]> writes: > Can can_ifindex be turned into a unsigned short? That way we would > have it nicely packed, avoiding this hole: Since dev->ifindex is int and we have many assignments between can_ifindex and dev->ifindex it would not make sense to define can_ifindex as a short int. Also in user space, ifindex is int, e.g. in struct ifreq. This would cause implicit truncating type casts from int to short int (some compilers warn about this, haven't tried GCC for a long time) or require many explicit type casts. Quick answer, thank you. - Arnaldo - 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] libertas: skb dereferenced after netif_rx
In libertas_process_rxed_packet() and process_rxed_802_11_packet() the
skb is dereferenced after being passed to netif_rx (called from
libertas_upload_rx_packet). Spotted by Coverity (1658, 1659).
Also, libertas_upload_rx_packet() unconditionally returns 0 so the error
check is dead code - might as well take it out.
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
rx.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/libertas/rx.c
b/drivers/net/wireless/libertas/rx.c
index d17924f..5e98055 100644
--- a/drivers/net/wireless/libertas/rx.c
+++ b/drivers/net/wireless/libertas/rx.c
@@ -269,15 +269,11 @@ int libertas_process_rxed_packet(wlan_private * priv,
struct sk_buff *skb)
wlan_compute_rssi(priv, p_rx_pd);
lbs_pr_debug(1, "RX Data: size of actual packet = %d\n", skb->len);
- if (libertas_upload_rx_packet(priv, skb)) {
- lbs_pr_debug(1, "RX error: libertas_upload_rx_packet"
- " returns failure\n");
- ret = -1;
- goto done;
- }
priv->stats.rx_bytes += skb->len;
priv->stats.rx_packets++;
+ libertas_upload_rx_packet(priv, skb);
+
ret = 0;
done:
LEAVE();
@@ -438,17 +434,11 @@ static int process_rxed_802_11_packet(wlan_private *
priv, struct sk_buff *skb)
wlan_compute_rssi(priv, prxpd);
lbs_pr_debug(1, "RX Data: size of actual packet = %d\n", skb->len);
-
- if (libertas_upload_rx_packet(priv, skb)) {
- lbs_pr_debug(1, "RX error: libertas_upload_rx_packet "
- "returns failure\n");
- ret = -1;
- goto done;
- }
-
priv->stats.rx_bytes += skb->len;
priv->stats.rx_packets++;
+ libertas_upload_rx_packet(priv, skb);
+
ret = 0;
done:
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
PROBLEM: SIS900 Driver change in Linux Kernel 2.6.21 causes kernel panic.
Kernel version 2.6.20.4 works. What I'm experiencing is a kernel panic as soon as the first received packet comes in via the sis900 ethernet interface. The machine is locked up and part of the kernel panic message is lost as it has scrolled off the screen and the virtual terminal has crashed as well (the kernel appears to have done a permanent halt - the keyboard LEDs are flashing). The only way I could get the machine to boot without this problem was to unplug the ethernet cable - but it would appear as soon as the the first packet was received after plugging the cable back in. That's not good since the machine in question is a server in a co-location facility (I can't print the screen either). The kernel panic was repeatable without fail. As this usually happens before "init" is called, the only "program" running is the kernel itself. I don't have any syslog/dmesg message recorded to disk for the event. I've rolled back to version 2.6.20.4 in the meantime. Hardware: Motherboard is a PC Chips M810LR Revision 5.0 with an AMD Athlon T-bird series 1100/200FSB CPU and 1Gb of PC133 SDRAM. (Yes, it's an older machine, but its load isn't that great). I compiled the kernel from a full source tar-ball, not from a patched source based on a prior version. What I could get from the kernel symbol traceback is that the first symbol happens to be "sis900_rxbuf" (or something like that) - which confirms to me that it is definently this driver that has the problem. I compile the driver directly into the kernel - I'm not using it as a module. Whatever changes were done, it's obvious that the driver is receiving a packet before some data structure is ready to handle it and the kernel is fatally exiting as a result. Although there are two changes (2.6.20.4 -> 2.6.21), I suspect that the first one is the cause of the problem. --- http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.21 commit b748d9e3b80dc7e6ce6bf7399f57964b99a4104c Author: Neil Horman <[EMAIL PROTECTED]> Date: Fri Apr 20 09:54:58 2007 -0400 sis900: Allocate rx replacement buffer before rx operation The sis900 driver appears to have a bug in which the receive routine passes the skbuff holding the received frame to the network stack before refilling the buffer in the rx ring. If a new skbuff cannot be allocated, the driver simply leaves a hole in the rx ring, which causes the driver to stop receiving frames and become non-recoverable without an rmmod/insmod according to reporters. This patch reverses that order, attempting to allocate a replacement buffer first, and receiving the new frame only if one can be allocated. If no skbuff can be allocated, the current skbuf in the rx ring is recycled, dropping the current frame, but keeping the NIC operational. Signed-off-by: Neil Horman <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> commit f3be97427172856d6865ddfedea84fa3a9f33227 Author: Andrew Morton <[EMAIL PROTECTED]> Date: Tue Mar 6 02:41:55 2007 -0800 sis900 warning fixes drivers/net/sis900.c: In function 'sis900_reset_phy': drivers/net/sis900.c:972: warning: 'status' may be used uninitialized in this function drivers/net/sis900.c: In function 'sis900_check_mode': drivers/net/sis900.c:1431: warning: 'status' may be used uninitialized in this function drivers/net/sis900.c: In function 'sis900_timer': drivers/net/sis900.c:1467: warning: 'status' may be used uninitialized in this function Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> --- !sh /usr/src/linux/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux snarked.org 2.6.20.4 #1 Mon May 7 22:52:04 UTC 2007 i686 unknown unknown GNU/Linux Gnu C 3.3.6 Gnu make 3.80 binutils 2.17.50.0.6 util-linux 2.12r mount 2.12r module-init-tools implemented e2fsprogs 1.38 jfsutils 1.1.8 reiserfsprogs 3.6.19 xfsprogs 2.6.13 pcmcia-cs 3.2.8 quota-tools3.12. PPP2.4.1 nfs-utils 1.0.7 Linux C Library2.3.5 Dynamic linker (ldd) 2.3.5 Linux C++ Library 5.0.7 Procps 3.2.5 Net-tools 1.60 Kbd1.12 oprofile 0.9.1 Sh-utils 5.2.1 udev 064 Modules Loaded (none) !lspci -vvv 00:00.0 0600: 1039:0730 (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR
[PATCH 0/10] spidernet assorted fixes
Jeff, Please apply & forward upstream the following patch series. There's a variety of fixes & cleanups in here; the key fix is a rather hard-to-reproduce bug where the hardware runs out of ram, resulting in corruption of some sequencer. The only fix is to reset the card. v-v Unfortunately, this hard-to-repro bug is hit during the fedora-core install process. Ugh. --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
[PATCH 1/10] spidernet: node-aware skbuff allocation
From: Christoph Hellwig <[EMAIL PROTECTED]>
Spidernet was the driver I original did all the node-aware netdevice
allocation for, but after a year it still hasn't hit mainline.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.22-rc1/drivers/net/spider_net.c
===
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-05-16
11:58:41.0 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-16 12:00:25.0
-0500
@@ -430,7 +430,8 @@ spider_net_prepare_rx_descr(struct spide
/* and we need to have it 128 byte aligned, therefore we allocate a
* bit more */
/* allocate an skb */
- descr->skb = dev_alloc_skb(bufsize + SPIDER_NET_RXBUF_ALIGN - 1);
+ descr->skb = netdev_alloc_skb(card->netdev,
+ bufsize + SPIDER_NET_RXBUF_ALIGN - 1);
if (!descr->skb) {
if (netif_msg_rx_err(card) && net_ratelimit())
pr_err("Not enough memory to allocate rx buffer\n");
-
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] TCP slow start: comments and cleanup
Add more comments to describe our version of tcp_slow_start().
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/ipv4/tcp_cong.c | 40 ++--
1 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
index 86b2653..bd74e43 100644
--- a/net/ipv4/tcp_cong.c
+++ b/net/ipv4/tcp_cong.c
@@ -276,30 +276,34 @@ int tcp_set_congestion_control(struct sock *sk, const
char *name)
/*
- * Slow start (exponential increase) with
- * RFC3742 Limited Slow Start (fast linear increase) support.
+ * Slow start is used when congestion window is less than slow start
+ * threshold. This version implements the basic RFC2581 version
+ * and optionally supports:
+ * RFC3742 Limited Slow Start- growth limited to max_ssthresh
+ * RFC3465 Appropriate Byte Counting - growth limited by bytes acknowledged
*/
void tcp_slow_start(struct tcp_sock *tp)
{
- int cnt = 0;
-
- if (sysctl_tcp_abc) {
- /* RFC3465: Slow Start
-* TCP sender SHOULD increase cwnd by the number of
-* previously unacknowledged bytes ACKed by each incoming
-* acknowledgment, provided the increase is not more than L
-*/
- if (tp->bytes_acked < tp->mss_cache)
- return;
- }
+ int cnt; /* increase in packets */
+
+ /* RFC3465: ABC Slow start
+* Increase only after a full MSS of bytes is acked
+*
+* TCP sender SHOULD increase cwnd by the number of
+* previously unacknowledged bytes ACKed by each incoming
+* acknowledgment, provided the increase is not more than L
+*/
+ if (sysctl_tcp_abc && tp->bytes_acked < tp->mss_cache)
+ return;
- if (sysctl_tcp_max_ssthresh > 0 &&
- tp->snd_cwnd > sysctl_tcp_max_ssthresh)
- cnt += sysctl_tcp_max_ssthresh>>1;
+ if (sysctl_tcp_max_ssthresh > 0 && tp->snd_cwnd >
sysctl_tcp_max_ssthresh)
+ cnt = sysctl_tcp_max_ssthresh >> 1; /* limited slow start */
else
- cnt += tp->snd_cwnd;
+ cnt = tp->snd_cwnd; /* exponential increase
*/
- /* RFC3465: We MAY increase by 2 if discovered delayed ack */
+ /* RFC3465: ABC
+* We MAY increase by 2 if discovered delayed ack
+*/
if (sysctl_tcp_abc > 1 && tp->bytes_acked >= 2*tp->mss_cache)
cnt <<= 1;
tp->bytes_acked = 0;
--
1.4.4.2
-
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/10] spidernet: beautify error messages
Make error messages print which interface they apply to.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 10 ++
drivers/net/spider_net.h |2 +-
2 files changed, 7 insertions(+), 5 deletions(-)
Index: linux-2.6.22-rc1/drivers/net/spider_net.c
===
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-05-14
17:05:03.0 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-15 14:47:38.0
-0500
@@ -433,7 +433,8 @@ spider_net_prepare_rx_descr(struct spide
descr->skb = dev_alloc_skb(bufsize + SPIDER_NET_RXBUF_ALIGN - 1);
if (!descr->skb) {
if (netif_msg_rx_err(card) && net_ratelimit())
- pr_err("Not enough memory to allocate rx buffer\n");
+ pr_err("%s: Not enough memory to allocate rx buffer\n",
+ card->netdev->name);
card->spider_stats.alloc_rx_skb_error++;
return -ENOMEM;
}
@@ -454,7 +455,8 @@ spider_net_prepare_rx_descr(struct spide
dev_kfree_skb_any(descr->skb);
descr->skb = NULL;
if (netif_msg_rx_err(card) && net_ratelimit())
- pr_err("Could not iommu-map rx buffer\n");
+ pr_err("%s: Could not iommu-map rx buffer\n",
+ card->netdev->name);
card->spider_stats.rx_iommu_map_error++;
hwdescr->dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
} else {
@@ -1454,8 +1456,8 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_GRFAFLLINT: /* fallthrough */
case SPIDER_NET_GRMFLLINT:
if (netif_msg_intr(card) && net_ratelimit())
- pr_err("Spider RX RAM full, incoming packets "
- "might be discarded!\n");
+ pr_err("%s: Spider RX RAM full, incoming packets "
+ "might be discarded!\n", card->netdev->name);
spider_net_rx_irq_off(card);
netif_rx_schedule(card->netdev);
show_error = 0;
Index: linux-2.6.22-rc1/drivers/net/spider_net.h
===
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.h 2007-05-15
14:47:33.0 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.h 2007-05-15 14:47:58.0
-0500
@@ -25,7 +25,7 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
-#define VERSION "2.0 A"
+#define VERSION "2.0 B"
#include "sungem_phy.h"
-
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] e1000: Fix msi enable leak on error, don't print error message, cleanup
Rick Jones wrote: Agreed. But is the PCI (?) subsystem doing something in that regard or is this a hole? Depends on your platform, your BIOS, your kernel command line, ... :) 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
[PATCH 3/10] spidernet: move a block of code around
Put the enable and disable routines next to one-another,
as this makes verifying thier symmetry that much easier.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
Index: linux-2.6.22-rc1/drivers/net/spider_net.c
===
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-05-15
13:31:05.0 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-15 13:31:11.0
-0500
@@ -505,6 +505,20 @@ spider_net_enable_rxdmac(struct spider_n
}
/**
+ * spider_net_disable_rxdmac - disables the receive DMA controller
+ * @card: card structure
+ *
+ * spider_net_disable_rxdmac terminates processing on the DMA controller
+ * by turing off the DMA controller, with the force-end flag set.
+ */
+static inline void
+spider_net_disable_rxdmac(struct spider_net_card *card)
+{
+ spider_net_write_reg(card, SPIDER_NET_GDADMACCNTR,
+SPIDER_NET_DMA_RX_FEND_VALUE);
+}
+
+/**
* spider_net_refill_rx_chain - refills descriptors/skbs in the rx chains
* @card: card structure
*
@@ -656,20 +670,6 @@ write_hash:
}
/**
- * spider_net_disable_rxdmac - disables the receive DMA controller
- * @card: card structure
- *
- * spider_net_disable_rxdmac terminates processing on the DMA controller by
- * turing off DMA and issueing a force end
- */
-static void
-spider_net_disable_rxdmac(struct spider_net_card *card)
-{
- spider_net_write_reg(card, SPIDER_NET_GDADMACCNTR,
-SPIDER_NET_DMA_RX_FEND_VALUE);
-}
-
-/**
* spider_net_prepare_tx_descr - fill tx descriptor with skb data
* @card: card structure
* @descr: descriptor structure to fill out
-
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 4/10] spidernet: zero out a pointer.
Invalidate a pointer as its pci_unmap'ed; this is a bit of
paranoia to make sure hardware doesn't continue trying to
DMA to it.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Index: linux-2.6.22-rc1/drivers/net/spider_net.c
===
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-05-15
13:31:11.0 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-15 13:31:16.0
-0500
@@ -1068,6 +1068,7 @@ spider_net_decode_one_descr(struct spide
struct spider_net_descr_chain *chain = &card->rx_chain;
struct spider_net_descr *descr = chain->tail;
struct spider_net_hw_descr *hwdescr = descr->hwdescr;
+ u32 hw_buf_addr;
int status;
status = spider_net_get_descr_status(hwdescr);
@@ -1081,7 +1082,9 @@ spider_net_decode_one_descr(struct spide
chain->tail = descr->next;
/* unmap descriptor */
- pci_unmap_single(card->pdev, hwdescr->buf_addr,
+ hw_buf_addr = hwdescr->buf_addr;
+ hwdescr->buf_addr = 0x0;
+ pci_unmap_single(card->pdev, hw_buf_addr,
SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
if ( (status == SPIDER_NET_DESCR_RESPONSE_ERROR) ||
@@ -1117,7 +1120,7 @@ spider_net_decode_one_descr(struct spide
pr_err("%s: bad status, cmd_status=x%08x\n",
card->netdev->name,
hwdescr->dmac_cmd_status);
- pr_err("buf_addr=x%08x\n", hwdescr->buf_addr);
+ pr_err("buf_addr=x%08x\n", hw_buf_addr);
pr_err("buf_size=x%08x\n", hwdescr->buf_size);
pr_err("next_descr_addr=x%08x\n", hwdescr->next_descr_addr);
pr_err("result_size=x%08x\n", hwdescr->result_size);
-
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: [WIP] [PATCH] WAS Re: [RFC] New driver API to speed up small packets xmits
Jamal,
Here are some comments i have on your patch.
See them inline.
Thanks
Sridhar
+static int try_get_tx_pkts(struct net_device *dev, struct Qdisc *q, int count)
+{
+ struct sk_buff *skb;
+ struct sk_buff_head *skbs = &dev->blist;
+ int tdq = count;
+
+ /*
+* very unlikely, but who knows ..
+* If this happens we dont try to grab more pkts
+*/
+ if (!skb_queue_empty(&dev->blist))
+ return skb_queue_len(&dev->blist);
+
+ if (dev->gso_skb) {
+ count--;
+ __skb_queue_head(skbs, dev->gso_skb);
+ dev->gso_skb = NULL;
+ }
AFAIK, gso_skb can be a list of skb's. Can we add a list
to another list using __skb_queue_head()?
Also, if gso_skb is a list of multiple skb's, i think the
count needs to be decremented by the number of segments in
gso_skb.
+
+ while (count) {
+ skb = q->dequeue(q);
+ if (!skb)
+ break;
+ count--;
+ __skb_queue_head(skbs, skb);
+ }
+
+ return tdq - count;
+}
+
+static inline int try_tx_pkts(struct net_device *dev)
+{
+
+ return dev->hard_batch_xmit(&dev->blist, dev);
+
+}
+
+/* same comments as in qdisc_restart apply;
+ * at some point use shared code with qdisc_restart*/
+int batch_qdisc_restart(struct net_device *dev)
+{
+ struct Qdisc *q = dev->qdisc;
+ unsigned lockless = (dev->features & NETIF_F_LLTX);
+ int count = dev->xmit_win;
+ int ret = 0;
+
+ ret = try_get_tx_pkts(dev, q, count);
+
+ if (ret == 0)
+ return qdisc_qlen(q);
+
+ /* we have packets to send! */
+ if (!lockless) {
+ if (!netif_tx_trylock(dev))
+ return tx_islocked(NULL, dev, q);
+ }
+
+ /* all clear .. */
+ spin_unlock(&dev->queue_lock);
+
+ ret = NETDEV_TX_BUSY;
+ if (!netif_queue_stopped(dev))
+ ret = try_tx_pkts(dev);
try_tx_pkts() is directly calling the device's batch xmit routine.
Don't we need to call dev_hard_start_xmit() to handle dev_queue_xmit_nit
and GSO segmentation?
+
+ if (!lockless)
+ netif_tx_unlock(dev);
+
+ spin_lock(&dev->queue_lock);
+
+ q = dev->qdisc;
+
+ /* most likely result, packet went ok */
+ if (ret == NETDEV_TX_OK)
+ return qdisc_qlen(q);
+ /* only for lockless drivers .. */
+ if (ret == NETDEV_TX_LOCKED && lockless)
+ return tx_islocked(NULL, dev, q);
+
+ if (unlikely(ret != NETDEV_TX_BUSY && net_ratelimit()))
+ printk(KERN_WARNING " BUG %s code %d qlen %d\n",
+ dev->name, ret, q->q.qlen);
+
+ return do_dev_requeue(NULL, dev, q);
+}
-
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 5/10] spidernet: null out skb pointer after its been used.
If the ethernet interface is brought down while there is still RX traffic in flight, the device shutdown routine can end up trying to double-free an skb, leading to a crash in mm/slab.c Avoid the double-free by nulling out the skb pointer. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> drivers/net/spider_net.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.22-rc1/drivers/net/spider_net.c === --- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-05-15 14:36:13.0 -0500 +++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-15 14:39:18.0 -0500 @@ -1135,6 +1135,7 @@ spider_net_decode_one_descr(struct spide /* Ok, we've got a packet in descr */ spider_net_pass_skb_up(descr, card); + descr->skb = NULL; hwdescr->dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE; return 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
[PATCH 6/10] spidernet: Don't terminate the RX ring
There is no real reason to terminate the RX ring; it
doesn't make the operation any smooother, and it does
require an extra sync. So don't do it.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Index: linux-2.6.22-rc1/drivers/net/spider_net.c
===
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-05-15
13:31:16.0 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-15 13:51:39.0
-0500
@@ -461,13 +461,9 @@ spider_net_prepare_rx_descr(struct spide
hwdescr->dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
} else {
hwdescr->buf_addr = buf;
- hwdescr->next_descr_addr = 0;
wmb();
hwdescr->dmac_cmd_status = SPIDER_NET_DESCR_CARDOWNED |
SPIDER_NET_DMAC_NOINTR_COMPLETE;
-
- wmb();
- descr->prev->hwdescr->next_descr_addr = descr->bus_addr;
}
return 0;
@@ -556,12 +552,16 @@ spider_net_refill_rx_chain(struct spider
static int
spider_net_alloc_rx_skbs(struct spider_net_card *card)
{
- int result;
- struct spider_net_descr_chain *chain;
+ struct spider_net_descr_chain *chain = &card->rx_chain;
+ struct spider_net_descr *start= chain->tail;
+ struct spider_net_descr *descr = start;
- result = -ENOMEM;
+ /* Link up the hardware chain pointers */
+ do {
+ descr->prev->hwdescr->next_descr_addr = descr->bus_addr;
+ descr = descr->next;
+ } while (descr != start);
- chain = &card->rx_chain;
/* Put at least one buffer into the chain. if this fails,
* we've got a problem. If not, spider_net_refill_rx_chain
* will do the rest at the end of this function. */
@@ -578,7 +578,7 @@ spider_net_alloc_rx_skbs(struct spider_n
error:
spider_net_free_rx_chain_contents(card);
- return result;
+ return -ENOMEM;
}
/**
-
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 7/10] spidernet: enhance the dump routine
Crazy device problems are hard to debug, when one does not have
good trace info. This patch makes a major enhancement to the
device dump routine.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 62 ---
1 file changed, 54 insertions(+), 8 deletions(-)
Index: linux-2.6.22-rc1/drivers/net/spider_net.c
===
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-05-15
14:39:24.0 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-15 14:39:25.0
-0500
@@ -1023,34 +1023,78 @@ spider_net_pass_skb_up(struct spider_net
card->netdev_stats.rx_bytes += skb->len;
}
-#ifdef DEBUG
static void show_rx_chain(struct spider_net_card *card)
{
struct spider_net_descr_chain *chain = &card->rx_chain;
struct spider_net_descr *start= chain->tail;
struct spider_net_descr *descr= start;
+ struct spider_net_hw_descr *hwd = start->hwdescr;
+ char *iface = card->netdev->name;
+ u32 curr_desc, next_desc;
int status;
int cnt = 0;
- int cstat = spider_net_get_descr_status(descr);
- printk(KERN_INFO "RX chain tail at descr=%ld\n",
-(start - card->descr) - card->tx_chain.num_desc);
+ int off = 0;
+ int cstat = hwd->dmac_cmd_status;
+
+ printk(KERN_INFO "%s: Total number of descrs=%d\n",
+ iface, chain->num_desc);
+ printk(KERN_INFO "%s: Chain tail located at descr=%d\n",
+ iface, (int) (start - chain->ring));
+
+ curr_desc = spider_net_read_reg(card, SPIDER_NET_GDACTDPA);
+ next_desc = spider_net_read_reg(card, SPIDER_NET_GDACNEXTDA);
+
status = cstat;
do
{
- status = spider_net_get_descr_status(descr);
+ hwd = descr->hwdescr;
+ off = descr - chain->ring;
+ if (descr==chain->head)
+ printk(KERN_INFO "%s: chain head is at %d\n", iface,
off);
+ if (curr_desc == descr->bus_addr)
+ printk(KERN_INFO "%s: hw curr desc is at %d\n", iface,
off);
+ if (next_desc == descr->bus_addr)
+ printk(KERN_INFO "%s: hw next desc is at %d\n", iface,
off);
+ if (hwd->next_descr_addr == 0)
+ printk(KERN_INFO "%s: chain is cut at %d\n", iface,
off);
+ status = hwd->dmac_cmd_status;
if (cstat != status) {
- printk(KERN_INFO "Have %d descrs with stat=x%08x\n",
cnt, cstat);
+ printk(KERN_INFO "%s: Have %d descrs with stat=x%08x\n",
+ iface, cnt, cstat);
cstat = status;
cnt = 0;
}
cnt ++;
descr = descr->next;
} while (descr != start);
- printk(KERN_INFO "Last %d descrs with stat=x%08x\n", cnt, cstat);
-}
+ printk(KERN_INFO "%s: Last %d descrs with stat=x%08x\n",
+ iface, cnt, cstat);
+
+#ifdef DEBUG
+ /* Now dump the whole ring */
+ descr = start;
+ do
+ {
+ struct spider_net_hw_descr *hwd = descr->hwdescr;
+ status = spider_net_get_descr_status(hwd);
+ cnt = descr - chain->ring;
+ printk(KERN_INFO "Descr %d stat=0x%08x skb=%p\n",
+ cnt, status, descr->skb);
+ printk(KERN_INFO "bus addr=%08x buf addr=%08x sz=%d\n",
+ descr->bus_addr, hwd->buf_addr, hwd->buf_size);
+ printk(KERN_INFO "next=%08x result sz=%d valid sz=%d\n",
+ hwd->next_descr_addr, hwd->result_size,
hwd->valid_size);
+ printk(KERN_INFO "dmac=%08x data stat=%08x data err=%08x\n",
+ hwd->dmac_cmd_status, hwd->data_status,
hwd->data_error);
+ printk(KERN_INFO "\n");
+
+ descr = descr->next;
+ } while (descr != start);
#endif
+}
+
/**
* spider_net_decode_one_descr - processes an RX descriptor
* @card: card structure
@@ -1140,6 +1184,8 @@ spider_net_decode_one_descr(struct spide
return 1;
bad_desc:
+ if (netif_msg_rx_err(card))
+ show_rx_chain(card);
dev_kfree_skb_irq(descr->skb);
descr->skb = NULL;
hwdescr->dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
-
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: PROBLEM: SIS900 Driver change in Linux Kernel 2.6.21 causes kernel panic.
On Wed, May 16, 2007 at 02:33:18PM -0700, - wrote: > Kernel version 2.6.20.4 works. What I'm experiencing is a kernel panic as > soon as the first received packet comes in via the sis900 ethernet > interface. The machine is locked up and part of the kernel panic message > is lost as it has scrolled off the screen and the virtual terminal has > crashed as well (the kernel appears to have done a permanent halt - the > keyboard LEDs are flashing). The only way I could get the machine to boot > without this problem was to unplug the ethernet cable - but it would > appear as soon as the the first packet was received after plugging the > cable back in. That's not good since the machine in question is a server > in a co-location facility (I can't print the screen either). The kernel > panic was repeatable without fail. As this usually happens before "init" > is called, the only "program" running is the kernel itself. I don't have > any syslog/dmesg message recorded to disk for the event. I've rolled back > to version 2.6.20.4 in the meantime. You need this.. http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=dc5a144991ba803bc8afded105c9db1dea0e57ab Which is queued for -stable afaik, but no sign of 2.6.21.2 yet. Greg/Chris? Dave -- http://www.codemonkey.org.uk - 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 8/10] spidernet: reset the card when an rxramfull is seen
Some versions of the spider have a firmware bug, where the
RX ring sequencer goes crazy when the RX RAM on the device
fills up. Appearently the only viable wrkaround is a soft
reset of the card.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
Index: linux-2.6.22-rc1/drivers/net/spider_net.c
===
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-05-15
14:48:06.0 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-15 16:34:46.0
-0500
@@ -1505,11 +1505,17 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_GRFBFLLINT: /* fallthrough */
case SPIDER_NET_GRFAFLLINT: /* fallthrough */
case SPIDER_NET_GRMFLLINT:
- if (netif_msg_intr(card) && net_ratelimit())
- pr_err("%s: Spider RX RAM full, incoming packets "
- "might be discarded!\n", card->netdev->name);
+ if (netif_msg_intr(card) && net_ratelimit()) {
+ pr_err("%s: Spider RX RAM full, reseting device.\n",
+ card->netdev->name);
+ show_rx_chain(card);
+ }
spider_net_rx_irq_off(card);
netif_rx_schedule(card->netdev);
+
+ /* If the card is spewing rxramfulls, then reset */
+ atomic_inc(&card->tx_timeout_task_counter);
+ schedule_work(&card->tx_timeout_task);
show_error = 0;
break;
@@ -2086,6 +2092,8 @@ spider_net_workaround_rxramfull(struct s
{
int i, sequencer = 0;
+ printk(KERN_INFO "%s: calling rxramfull workaround\n",
card->netdev->name);
+
/* cancel reset */
spider_net_write_reg(card, SPIDER_NET_CKRCTRL,
SPIDER_NET_CKRCTRL_RUN_VALUE);
-
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 9/10] spidernet: service TX later.
When entering the netdev poll routine, empty out the RX
chain first, before cleaning up the TX chain. This should
help avoid RX buffer overflows.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.22-rc1/drivers/net/spider_net.c
===
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-05-16
17:20:36.0 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-16 17:20:44.0
-0500
@@ -1212,7 +1212,6 @@ spider_net_poll(struct net_device *netde
int packets_to_do, packets_done = 0;
int no_more_packets = 0;
- spider_net_cleanup_tx_ring(card);
packets_to_do = min(*budget, netdev->quota);
while (packets_to_do) {
@@ -1231,6 +1230,8 @@ spider_net_poll(struct net_device *netde
spider_net_refill_rx_chain(card);
spider_net_enable_rxdmac(card);
+ spider_net_cleanup_tx_ring(card);
+
/* if all packets are in the stack, enable interrupts and return 0 */
/* if not, return 1 */
if (no_more_packets) {
-
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 10/10] spidernet: increase the NAPI weight
Another way of minimizing the likelyhood of RX ram from overflowing is to empty out the entire rx ring every chance we get. Change the crazy watchdog timeout from 50 seconds to 3 seconds, while we're here. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> drivers/net/spider_net.h |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) Index: linux-2.6.22-rc1/drivers/net/spider_net.h === --- linux-2.6.22-rc1.orig/drivers/net/spider_net.h 2007-05-16 12:00:35.0 -0500 +++ linux-2.6.22-rc1/drivers/net/spider_net.h 2007-05-16 12:00:35.0 -0500 @@ -56,8 +56,13 @@ extern char spider_net_driver_name[]; #define SPIDER_NET_RX_CSUM_DEFAULT 1 -#define SPIDER_NET_WATCHDOG_TIMEOUT50*HZ -#define SPIDER_NET_NAPI_WEIGHT 64 +#define SPIDER_NET_WATCHDOG_TIMEOUT3*HZ + +/* We really really want to empty the ring buffer every time, + * so as to avoid the RX ram full bug. So set te napi wieght + * to the ring size + */ +#define SPIDER_NET_NAPI_WEIGHT SPIDER_NET_RX_DESCRIPTORS_DEFAULT #define SPIDER_NET_FIRMWARE_SEQS 6 #define SPIDER_NET_FIRMWARE_SEQWORDS 1024 - 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] e1000: Work around 82571 completion timout on Pseries HW
On Wed, 2007-05-16 at 17:11 -0500, Wen Xiong wrote: > little history, on PCI-X adapters we did not time dma reads being > returned to the adapter. On PCIe unfortunately the spec says that > adapters need to time the dma reads the spec is not specific on the > range but the timers can range from worst case 50 usecs to 10 ms with > some adapters supporting upto 50ms. The PCIe spec has approved an ECR > to the PCIe 1.0a spec that will support the ability to disable the > timer. To work aroung the adapter doesn't support ECR. We need the > driver to disable the timer. You do get more than 10ms delay for DMA replies on pSeries ? Ouch... Ben. - 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: [WIP] [PATCH] WAS Re: [RFC] New driver API to speed up small packets xmits
On Wed, 2007-16-05 at 15:12 -0700, Sridhar Samudrala wrote: > Jamal, > > Here are some comments i have on your patch. > See them inline. > Thanks for taking the time Sridhar. > try_tx_pkts() is directly calling the device's batch xmit routine. > Don't we need to call dev_hard_start_xmit() to handle dev_queue_xmit_nit > and GSO segmentation? > I think this is the core of all your other comments. Good catch - that piece of code has changed since 2.6.18; so the patch i posted wont work with GSO. You actually caught a bug in my other patch as well that nobody else did;-> I will have to think a bit about this; i may end up coalescing when grabbing the packets but call the nit from the driver using a helper. 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] [NET_SCHED]make qdisc_restart more readable
On Mon, 2007-14-05 at 09:30 -0400, jamal wrote: > Incoporating last comments from Patrick. > Dave, I think this is ready to apply - against net-2.6 from this > morning. Dave - hold onto this patch - Sridhar Samudrala <[EMAIL PROTECTED]> caught a bug i need to fix (GSO wont work). The game starting in a few holds priority for now. I will send a patch either tonight or tommorow morning. Otoh, if you have applied it - it is a simple incremental patch. 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] [NET_SCHED]make qdisc_restart more readable
From: jamal <[EMAIL PROTECTED]> Date: Wed, 16 May 2007 18:55:04 -0400 > On Mon, 2007-14-05 at 09:30 -0400, jamal wrote: > > Incoporating last comments from Patrick. > > Dave, I think this is ready to apply - against net-2.6 from this > > morning. > > Dave - hold onto this patch - Sridhar Samudrala <[EMAIL PROTECTED]> caught > a bug i need to fix (GSO wont work). No problems, I'm busy with something else anyways. > The game starting in a few holds priority for now. And I can't say whether or not it is related to that :-) - 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.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523
On Wed, 16 May 2007, Jiri Kosina wrote: > > since Jiri has a good test case for it, I leave it to him for testing. > > If he confirms that this fixes the locking issues, then this is > > Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> > I will verify later this evening and will let you know. I am however > pretty convinced now that this is the right fix. Satyam, I have just verified that this locking scheme is indeed correct. So you can add Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> if you wish to, and submit the patch to Andrew. Thanks, -- Jiri Kosina - 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: [stable] PROBLEM: SIS900 Driver change in Linux Kernel 2.6.21 causes kernel panic.
On Wed, May 16, 2007 at 06:17:04PM -0400, Dave Jones wrote: > On Wed, May 16, 2007 at 02:33:18PM -0700, - wrote: > > Kernel version 2.6.20.4 works. What I'm experiencing is a kernel panic as > > soon as the first received packet comes in via the sis900 ethernet > > interface. The machine is locked up and part of the kernel panic message > > is lost as it has scrolled off the screen and the virtual terminal has > > crashed as well (the kernel appears to have done a permanent halt - the > > keyboard LEDs are flashing). The only way I could get the machine to boot > > without this problem was to unplug the ethernet cable - but it would > > appear as soon as the the first packet was received after plugging the > > cable back in. That's not good since the machine in question is a server > > in a co-location facility (I can't print the screen either). The kernel > > panic was repeatable without fail. As this usually happens before "init" > > is called, the only "program" running is the kernel itself. I don't have > > any syslog/dmesg message recorded to disk for the event. I've rolled back > > to version 2.6.20.4 in the meantime. > > You need this.. > > http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=dc5a144991ba803bc8afded105c9db1dea0e57ab > > Which is queued for -stable afaik, but no sign of 2.6.21.2 yet. Greg/Chris? I have a large queue backing up, will try to flush it out by tomorrow and get a review cycle started. thanks, greg "i'm starting to hate travelling" k-h - 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] [NET_SCHED]make qdisc_restart more readable
On Wed, 2007-05-16 at 18:55 -0400, jamal wrote: > On Mon, 2007-14-05 at 09:30 -0400, jamal wrote: > > Incoporating last comments from Patrick. > > Dave, I think this is ready to apply - against net-2.6 from this > > morning. > > Dave - hold onto this patch - Sridhar Samudrala <[EMAIL PROTECTED]> caught > a bug i need to fix (GSO wont work). I think your qdisc_restart() cleanup patch is OK. There you are still calling dev_hard_start_xmit() and GSO should work fine. But the batch xmit patch has some issues. Thanks Sridhar > The game starting in a few holds priority for now. I will send a patch > either tonight or tommorow morning. > Otoh, if you have applied it - it is a simple incremental patch. > > 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: 2.6.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523
From: Jiri Kosina <[EMAIL PROTECTED]> Date: Thu, 17 May 2007 01:03:55 +0200 (CEST) > On Wed, 16 May 2007, Jiri Kosina wrote: > > > > since Jiri has a good test case for it, I leave it to him for testing. > > > If he confirms that this fixes the locking issues, then this is > > > Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> > > I will verify later this evening and will let you know. I am however > > pretty convinced now that this is the right fix. > > Satyam, > > I have just verified that this locking scheme is indeed correct. So you > can add > > Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> > > if you wish to, and submit the patch to Andrew. I guess I don't get sent networking patches any more? :-) - 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.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523
On Wed, 16 May 2007, David Miller wrote: > > I have just verified that this locking scheme is indeed correct. So you > > can add > > > > Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> > > > > if you wish to, and submit the patch to Andrew. > I guess I don't get sent networking patches any more? > :-) Well, this is bluetooth-specific, but it seemed to me that Marcel wasn't going to send pull requests to Linus any time soon, therefore I thought going through akpm is a thing to do. Honestly, I really don't care through which tree this goes in, so sorry if any offence was caused here :) -- Jiri Kosina - 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: [Cbe-oss-dev] [PATCH 2/10] spidernet: beautify error messages
On Wed, 2007-05-16 at 17:00 -0500, Linas Vepstas wrote:
> Make error messages print which interface they apply to.
>
> Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
>
>
> drivers/net/spider_net.c | 10 ++
> drivers/net/spider_net.h |2 +-
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> Index: linux-2.6.22-rc1/drivers/net/spider_net.c
> ===
> --- linux-2.6.22-rc1.orig/drivers/net/spider_net.c2007-05-14
> 17:05:03.0 -0500
> +++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-15 14:47:38.0
> -0500
> @@ -433,7 +433,8 @@ spider_net_prepare_rx_descr(struct spide
> descr->skb = dev_alloc_skb(bufsize + SPIDER_NET_RXBUF_ALIGN - 1);
> if (!descr->skb) {
> if (netif_msg_rx_err(card) && net_ratelimit())
> - pr_err("Not enough memory to allocate rx buffer\n");
> + pr_err("%s: Not enough memory to allocate rx buffer\n",
> + card->netdev->name);
Isn't that what dev_err() is for?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
Re: [Cbe-oss-dev] [PATCH 4/10] spidernet: zero out a pointer.
On Wed, 2007-05-16 at 17:09 -0500, Linas Vepstas wrote: > Invalidate a pointer as its pci_unmap'ed; this is a bit of > paranoia to make sure hardware doesn't continue trying to > DMA to it. > > Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> > > > drivers/net/spider_net.c |7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > Index: linux-2.6.22-rc1/drivers/net/spider_net.c > === > --- linux-2.6.22-rc1.orig/drivers/net/spider_net.c2007-05-15 > 13:31:11.0 -0500 > +++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-15 13:31:16.0 > -0500 > @@ -1081,7 +1082,9 @@ spider_net_decode_one_descr(struct spide > chain->tail = descr->next; > > /* unmap descriptor */ > - pci_unmap_single(card->pdev, hwdescr->buf_addr, > + hw_buf_addr = hwdescr->buf_addr; > + hwdescr->buf_addr = 0x0; If you're going to be paranoid, shouldn't you do something here to make sure the value's hit the device? > + pci_unmap_single(card->pdev, hw_buf_addr, > SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE); > cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: [Cbe-oss-dev] [PATCH 10/10] spidernet: increase the NAPI weight
On Wed, 2007-05-16 at 17:23 -0500, Linas Vepstas wrote: > Another way of minimizing the likelyhood of RX ram from overflowing > is to empty out the entire rx ring every chance we get. Change > the crazy watchdog timeout from 50 seconds to 3 seconds, while > we're here. > > Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> > > > drivers/net/spider_net.h |9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > Index: linux-2.6.22-rc1/drivers/net/spider_net.h > === > --- linux-2.6.22-rc1.orig/drivers/net/spider_net.h2007-05-16 > 12:00:35.0 -0500 > +++ linux-2.6.22-rc1/drivers/net/spider_net.h 2007-05-16 12:00:35.0 > -0500 > @@ -56,8 +56,13 @@ extern char spider_net_driver_name[]; > > #define SPIDER_NET_RX_CSUM_DEFAULT 1 > > -#define SPIDER_NET_WATCHDOG_TIMEOUT 50*HZ > -#define SPIDER_NET_NAPI_WEIGHT 64 > +#define SPIDER_NET_WATCHDOG_TIMEOUT 3*HZ > + > +/* We really really want to empty the ring buffer every time, > + * so as to avoid the RX ram full bug. So set te napi wieght Speeeling .. ^^ ^^ cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
RT patches expose netdev race [was Re: [RFC] [patch 2/2] powerpc 2.6.21-rt1: fix kernel hang and/or panic
Hi, On Tue, May 15, 2007 at 08:09:02PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2007-05-15 at 17:47 +0900, Tsutomu OWA wrote: > > I encountered the following error when doing netperf from other machine > > to Celleb running RT kernel. PREEPT_NONE kernel works just fine as well. > > Hrm... sounds a bit weird. I wonder if there's a locking bug in the > driver in the first place. > > Linas, what's your take ? Heh. I almost deleted the entire email thread cause it didn't say "spidernet" in the subject line. :-) Seriously, I really almost did Since this is a long email; let me put a summary up front: I think the RT/premption patches are exposing some sort of race in the ip header handling code. The rest of the note is forensics pointing to this. Reading the patch, it looks like all it did was to move around the locks, without changing the semantics. Two comments about that: -- The current spidernet locks are very fine-grained; this makes the whole thing function more smoothly. The patch would make them coarse-grained, I don't like that. -- Moving around locks like that changes the timing completely, and changing the timing makes races come and go. The races seem to vanish, but that's only cause you are getting lucky. Since I'm sick-n-tired of dealing with spidernet, I thought I'd give this one a little extra attention. The crash is a null pointer deref. The spidernet doesn't use locks to protect null pointers. The spidernet mostly doesn't play with pointers at all; they're mostly static. So this crash is "unusual" from the get-go. >> Instruction dump: >> 6000 81790088 901f000c 913f0018 913f0008 917f0004 48132e8d >> 6000 >> a019009e 2f800800 409e0038 e9390038 <88690009> 2f830006 419e0010 >> 2f830011 The crashing instruction is <88690009> which is very unique: lbz r3,9(r9) load byte ... at an offset of 9 bytes!? spidernet does nothing with bytes, so its another reason its not spidernet. Below follows a manual disassembly. The guilty party appears to the the skb, and spcifically, skb->head has not been set. You'll have to read the details below to see why. I do not know why sk_buff->head would be null, or would be set in a racy kind of way, or why the rt patches would cause this. But the evidence implicates that. --linas Long stuff below. For the record: > > Unable to handle kernel paging request for data at address 0x0009 > > Faulting instruction address: 0xc0295434 > > Oops: Kernel access of bad area, sig: 11 [#1] > > PREEMPT SMP NR_CPUS=2 NUMA > > Modules linked in: > > NIP: C0295434 LR: C0295420 CTR: > > REGS: c95d6e30 TRAP: 0300 Not tainted (2.6.21-rc5-rt7) > > MSR: 80009032 CR: 24000482 XER: 2000 > > DAR: 0009, DSISR: 4000 > > TASK = c1e7c440[626] 'netserver' THREAD: c95d4000 CPU: 0 > > GPR00: 0800 C95D70B0 C05D77B8 0001 > > GPR04: 0001 C95D7080 > > GPR08: C95D7030 C95D7040 > > GPR12: FC69925300080D5D C04DE680 00422208 > > GPR16: 0040 00420D10 C95D7C88 > > GPR20: C1E7C440 0001 C8ACEAE0 > > GPR24: 0020 C0E50C80 81F84C5E C1C00BE0 > > GPR28: C1C05430 C1C00B80 C0570F30 C1FD1720 > > NIP [C0295434] .spider_net_xmit+0x1dc/0x448 > > LR [C0295420] .spider_net_xmit+0x1c8/0x448 > > Call Trace: > > [C95D70B0] [C0295420] .spider_net_xmit+0x1c8/0x448 > > (unreliable) > > [C95D7160] [C0327EE8] .dev_hard_start_xmit+0x238/0x300 > > [C95D7200] [C033A7F4] .__qdisc_run+0xdc/0x2a4 > > [C95D72B0] [C032A948] .dev_queue_xmit+0x1b0/0x2fc > > [C95D7350] [C034B470] .ip_output+0x280/0x2d8 > > [C95D73F0] [C034C6CC] .ip_queue_xmit+0x448/0x4d8 > > [C95D74F0] [C035F6D8] .tcp_transmit_skb+0x850/0x8c0 > > [C95D75C0] [C035C394] .__tcp_ack_snd_check+0x84/0xc0 > > [C95D7650] [C035E114] .tcp_rcv_established+0x4f0/0x8ac > > [C95D7700] [C0365B24] .tcp_v4_do_rcv+0x5c/0x448 > > [C95D77D0] [C031C2C4] .release_sock+0x94/0x11c > > [C95D7870] [C0354E7C] .tcp_recvmsg+0x374/0x8d8 > > [C95D7960] [C031B8A0] .sock_common_recvmsg+0x5c/0x84 > > [C95D79F0] [C031921C] .sock_recvmsg+0x110/0x15c > > [C95D7C00] [C031AA50] .sys_recvfrom+0xf0/0x174 > > [C95D7D90] [C0339368] .compat_sys_socketcall+0x178/0x214 > > [C95D7E30] [C0008634] syscall_exit+0x0/0x40 > > Instruction dump: > > 6000 81790088 901f000c 913f0018 913f0008 917f0004 48132e8d 6000 > > a019009e 2
Resending: RT patches expose netdev race [was Re: [RFC] [patch 2/2] powerpc 2.6.21-rt1: fix kernel hang and/or panic
(resending , Owa-san was cut from cc list!??) Hi, On Tue, May 15, 2007 at 08:09:02PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2007-05-15 at 17:47 +0900, Tsutomu OWA wrote: > > I encountered the following error when doing netperf from other machine > > to Celleb running RT kernel. PREEPT_NONE kernel works just fine as well. > > Hrm... sounds a bit weird. I wonder if there's a locking bug in the > driver in the first place. > > Linas, what's your take ? Heh. I almost deleted the entire email thread cause it didn't say "spidernet" in the subject line. :-) Seriously, I really almost did Since this is a long email; let me put a summary up front: I think the RT/premption patches are exposing some sort of race in the ip header handling code. The rest of the note is forensics pointing to this. Reading the patch, it looks like all it did was to move around the locks, without changing the semantics. Two comments about that: -- The current spidernet locks are very fine-grained; this makes the whole thing function more smoothly. The patch would make them coarse-grained, I don't like that. -- Moving around locks like that changes the timing completely, and changing the timing makes races come and go. The races seem to vanish, but that's only cause you are getting lucky. Since I'm sick-n-tired of dealing with spidernet, I thought I'd give this one a little extra attention. The crash is a null pointer deref. The spidernet doesn't use locks to protect null pointers. The spidernet mostly doesn't play with pointers at all; they're mostly static. So this crash is "unusual" from the get-go. >> Instruction dump: >> 6000 81790088 901f000c 913f0018 913f0008 917f0004 48132e8d >> 6000 >> a019009e 2f800800 409e0038 e9390038 <88690009> 2f830006 419e0010 >> 2f830011 The crashing instruction is <88690009> which is very unique: lbz r3,9(r9) load byte ... at an offset of 9 bytes!? spidernet does nothing with bytes, so its another reason its not spidernet. Below follows a manual disassembly. The guilty party appears to the the skb, and spcifically, skb->head has not been set. You'll have to read the details below to see why. I do not know why sk_buff->head would be null, or would be set in a racy kind of way, or why the rt patches would cause this. But the evidence implicates that. --linas Long stuff below. For the record: > > Unable to handle kernel paging request for data at address 0x0009 > > Faulting instruction address: 0xc0295434 > > Oops: Kernel access of bad area, sig: 11 [#1] > > PREEMPT SMP NR_CPUS=2 NUMA > > Modules linked in: > > NIP: C0295434 LR: C0295420 CTR: > > REGS: c95d6e30 TRAP: 0300 Not tainted (2.6.21-rc5-rt7) > > MSR: 80009032 CR: 24000482 XER: 2000 > > DAR: 0009, DSISR: 4000 > > TASK = c1e7c440[626] 'netserver' THREAD: c95d4000 CPU: 0 > > GPR00: 0800 C95D70B0 C05D77B8 0001 > > GPR04: 0001 C95D7080 > > GPR08: C95D7030 C95D7040 > > GPR12: FC69925300080D5D C04DE680 00422208 > > GPR16: 0040 00420D10 C95D7C88 > > GPR20: C1E7C440 0001 C8ACEAE0 > > GPR24: 0020 C0E50C80 81F84C5E C1C00BE0 > > GPR28: C1C05430 C1C00B80 C0570F30 C1FD1720 > > NIP [C0295434] .spider_net_xmit+0x1dc/0x448 > > LR [C0295420] .spider_net_xmit+0x1c8/0x448 > > Call Trace: > > [C95D70B0] [C0295420] .spider_net_xmit+0x1c8/0x448 > > (unreliable) > > [C95D7160] [C0327EE8] .dev_hard_start_xmit+0x238/0x300 > > [C95D7200] [C033A7F4] .__qdisc_run+0xdc/0x2a4 > > [C95D72B0] [C032A948] .dev_queue_xmit+0x1b0/0x2fc > > [C95D7350] [C034B470] .ip_output+0x280/0x2d8 > > [C95D73F0] [C034C6CC] .ip_queue_xmit+0x448/0x4d8 > > [C95D74F0] [C035F6D8] .tcp_transmit_skb+0x850/0x8c0 > > [C95D75C0] [C035C394] .__tcp_ack_snd_check+0x84/0xc0 > > [C95D7650] [C035E114] .tcp_rcv_established+0x4f0/0x8ac > > [C95D7700] [C0365B24] .tcp_v4_do_rcv+0x5c/0x448 > > [C95D77D0] [C031C2C4] .release_sock+0x94/0x11c > > [C95D7870] [C0354E7C] .tcp_recvmsg+0x374/0x8d8 > > [C95D7960] [C031B8A0] .sock_common_recvmsg+0x5c/0x84 > > [C95D79F0] [C031921C] .sock_recvmsg+0x110/0x15c > > [C95D7C00] [C031AA50] .sys_recvfrom+0xf0/0x174 > > [C95D7D90] [C0339368] .compat_sys_socketcall+0x178/0x214 > > [C95D7E30] [C0008634] syscall_exit+0x0/0x40 > > Instruction dump: > > 6000 81790088 901f000c 913f0018 913f
Re: RT patches expose netdev race [was Re: [RFC] [patch 2/2] powerpc 2.6.21-rt1: fix kernel hang and/or panic
From: [EMAIL PROTECTED] (Linas Vepstas) Date: Wed, 16 May 2007 19:18:02 -0500 > Hi, > > On Tue, May 15, 2007 at 08:09:02PM +1000, Benjamin Herrenschmidt wrote: > > On Tue, 2007-05-15 at 17:47 +0900, Tsutomu OWA wrote: > > > I encountered the following error when doing netperf from other machine > > > to Celleb running RT kernel. PREEPT_NONE kernel works just fine as well. > > > > Hrm... sounds a bit weird. I wonder if there's a locking bug in the > > driver in the first place. > > > > Linas, what's your take ? > > Heh. I almost deleted the entire email thread cause it > didn't say "spidernet" in the subject line. :-) > Seriously, I really almost did > > Since this is a long email; let me put a summary up front: > I think the RT/premption patches are exposing some sort > of race in the ip header handling code. The rest of the > note is forensics pointing to this. skb->head should never ever be NULL. - 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] e1000: Work around 82571 completion timout on Pseries HW
On May 16, 2007, at 3:53 AM, Auke Kok wrote:
Our 82571 (first PCI-E hardware) causes P-Series hardware to throw
issues. Disabling PCI-E completion timeouts in our NIC resolves
the issue.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Cc: Wen Xiong <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/
e1000_main.c
index 49be393..830d851 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -819,6 +819,16 @@ e1000_reset(struct e1000_adapter *adapter)
E1000_WRITE_REG(&adapter->hw, CTRL, ctrl);
}
+#if defined(CONFIG_PPC64) || defined(CONFIG_PPC)
If this is really on need on pseries HW this should be #ifdef
CONFIG_PPC_PSERIES. No reason to force this on all PPC.
+#define E1000_GCR_DISABLE_TIMEOUT_MECHANISM 0x8000
+ if (adapter->hw.mac.type == e1000_82571) {
+ /* work around pSeries hardware by disabling timeouts */
+ u32 gcr = E1000_READ_REG(&adapter->hw, E1000_GCR);
+ gcr |= E1000_GCR_DISABLE_TIMEOUT_MECHANISM;
+ E1000_WRITE_REG(&adapter->hw, E1000_GCR, gcr);
+ }
+#endif
+
/* Enable h/w to recognize an 802.1Q VLAN Ethernet packet */
E1000_WRITE_REG(&adapter->hw, VET, ETHERNET_IEEE_VLAN_TYPE);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To 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: Resending: RT patches expose netdev race [was Re: [RFC] [patch 2/2] powerpc 2.6.21-rt1: fix kernel hang and/or panic
> I do not know why sk_buff->head would be null, or > would be set in a racy kind of way, or why the rt patches > would cause this. But the evidence implicates that. Would it be possible that a locking bug in spidernet would cause it under some circumstances to get a stale skb pointer ? Ben. - 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: select(0, ..) is valid ?
On Wed, 2007-05-16 at 10:37 -0500, Anton Blanchard wrote:
> Hi Hugh,
>
> > It's interesting that compat_core_sys_select() shows this kmalloc(0)
> > failure but core_sys_select() does not. That's because core_sys_select()
> > avoids kmalloc by using a buffer on the stack for small allocations (and
> > 0 sure is small). Shouldn't compat_core_sys_select() do just the same?
> > Or is SLUB going to be so efficient that doing so is a waste of time?
>
> Nice catch, the original optimisation from Andi is:
>
> http://git.kernel.org/git-new/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=70674f95c0a2ea694d5c39f4e514f538a09be36f
>
> And I think it makes sense for the compat code to do it too.
>
> Anton
Here it is ..
Should I do one for poll() also ?
Thanks,
Badari
Optimize select by a using stack space for small fd sets.
core_sys_select() already has this optimization. This is
for compat version.
Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]>
---
fs/compat.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
Index: linux-2.6.22-rc1/fs/compat.c
===
--- linux-2.6.22-rc1.orig/fs/compat.c 2007-05-12 18:45:56.0 -0700
+++ linux-2.6.22-rc1/fs/compat.c2007-05-16 17:50:39.0 -0700
@@ -1544,9 +1544,10 @@ int compat_core_sys_select(int n, compat
compat_ulong_t __user *outp, compat_ulong_t __user *exp, s64 *timeout)
{
fd_set_bits fds;
- char *bits;
+ void *bits;
int size, max_fds, ret = -EINVAL;
struct fdtable *fdt;
+ long stack_fds[SELECT_STACK_ALLOC/sizeof(long)];
if (n < 0)
goto out_nofds;
@@ -1564,11 +1565,14 @@ int compat_core_sys_select(int n, compat
* since we used fdset we need to allocate memory in units of
* long-words.
*/
- ret = -ENOMEM;
size = FDS_BYTES(n);
- bits = kmalloc(6 * size, GFP_KERNEL);
- if (!bits)
- goto out_nofds;
+ bits = stack_fds;
+ if (size > sizeof(stack_fds) / 6) {
+ bits = kmalloc(6 * size, GFP_KERNEL);
+ ret = -ENOMEM;
+ if (!bits)
+ goto out_nofds;
+ }
fds.in = (unsigned long *) bits;
fds.out = (unsigned long *) (bits + size);
fds.ex = (unsigned long *) (bits + 2*size);
@@ -1600,7 +1604,8 @@ int compat_core_sys_select(int n, compat
compat_set_fd_set(n, exp, fds.res_ex))
ret = -EFAULT;
out:
- kfree(bits);
+ if (bits != stack_fds)
+ kfree(bits);
out_nofds:
return ret;
}
-
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
