Hi Jiri,
> > > 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?
> > :-)
>
> We
Sridhar Samudrala <[EMAIL PROTECTED]> wrote on 05/17/2007 03:14:41 AM:
> Krishna Kumar2 wrote:
> > Hi Sridhar,
> >
> > Sridhar Samudrala <[EMAIL PROTECTED]> wrote on 05/17/2007 03:42:03 AM:
> >
> >> AFAIK, gso_skb can be a list of skb's. Can we add a list
> >> to another list using __skb_queue_hea
Krishna Kumar2 wrote:
Hi Sridhar,
Sridhar Samudrala <[EMAIL PROTECTED]> wrote on 05/17/2007 03:42:03 AM:
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
Hi Sridhar,
Sridhar Samudrala <[EMAIL PROTECTED]> wrote on 05/17/2007 03:42:03 AM:
> 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 se
On Wed, 2007-16-05 at 18:52 -0400, jamal wrote:
> On Wed, 2007-16-05 at 15:12 -0700, Sridhar Samudrala wrote:
>
> 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.
>
Thats what i did. This would hopefully
Jeff Garzik wrote:
Stephen has some sky2 patches I need to push. I accidentally filed them
until 'Pending: SATA', and they got missed in my most recent net driver
push.
Thanks, that clears it up, forgot to check netdev before asking. Looks
like the 2.6.22 plans are to drop the machine detect
Daniel Drake wrote:
Stephen Hemminger wrote:
It looks like these users aren't using MSI?
Possible. Want me to find out?
I just ask as I note yesterday's -stable patch where you remove the
#ifdef completely. Is that going to go upstream into 2.6.22 or do you
want to continue pursuing the DMI
* David Miller ([EMAIL PROTECTED]) wrote:
> We're not pushing this in, even the ipv6 working group is unsure
> how this should be handled and one of the possibilities they might
> choose matches how things currently are.
Alright, I'll drop this one from the -stable radar, thanks.
-chris
-
To unsub
On Wed, 2007-16-05 at 16:15 -0700, Sridhar Samudrala wrote:
>
> I think your qdisc_restart() cleanup patch is OK. There you are
> still calling dev_hard_start_xmit() and GSO should work fine.
Sorry, you are right - I thought i cutnpasted from it.
So Dave, false alarm ;-> That patch is clean.
>
Stephen Hemminger wrote:
It looks like these users aren't using MSI?
Possible. Want me to find out?
I just ask as I note yesterday's -stable patch where you remove the
#ifdef completely. Is that going to go upstream into 2.6.22 or do you
want to continue pursuing the DMI matching path?
Tha
* YOSHIFUJI Hideaki / 吉藤英明 ([EMAIL PROTECTED]) wrote:
> In article <[EMAIL PROTECTED]> (at Fri, 11 May 2007 09:22:43 -0700), Chris
> Wright <[EMAIL PROTECTED]> says:
> > * YOSHIFUJI Hideaki / 吉藤英明 ([EMAIL PROTECTED]) wrote:
> > > The "fix" for emerging security threats was overkill and it broke
>
* Dave Jones ([EMAIL PROTECTED]) wrote:
> 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?
Yes, it is queued,
The stats update code in spider_net_pass_skb_up() is touching the skb
after it's been passed up to the stack. To avoid that, just update the
stats first.
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
spider_net.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
* Stephen Hemminger ([EMAIL PROTECTED]) wrote:
> It looks like the problems of Gigabyte 88E8056 are unique to that chip
> motherboard and maybe fixable by EEPROM update.
So, drop the Gigabyte hunks in the original patch...ok, thanks.
-chris
-
To unsubscribe from this list: send the line "unsubscri
* Stephen Hemminger ([EMAIL PROTECTED]) wrote:
> - { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
> +// { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
Where-o-where are the CodingStyle police? ;-)
-
To unsubscribe from this list: send the line "unsubscribe netdev"
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
> 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.
-
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
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
(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
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.
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 Vep
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 +--
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(+),
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 m
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]>
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: Ma
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 lo
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
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 Samudra
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 ha
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 startin
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 wo
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 +++
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: lin
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 +++---
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 sc
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
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 deletion
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]>
d
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;
+
+ /*
+* v
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-r
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-
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
=
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
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/ne
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
i
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, th
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 w
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 - mig
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
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 al
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 206ebaf32795cf1582b1e2ff2ec6a560
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));
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 : M
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 obse
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 hea
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 pat
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
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 "nor
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
"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
ca
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 rat
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
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
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 (r
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 --
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/ne
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
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 the
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.
> + */
> +st
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
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 driv
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
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 fi
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 in
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 l
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 th
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 ma
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 i
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 l
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
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 +++
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 *ada
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 +
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
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, an
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-r
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 +
inc
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 "
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 an
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;
[...]
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
=
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/Docu
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
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);
> > > > > > +
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 NS
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(s
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(s
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_ne
1 - 100 of 115 matches
Mail list logo