headers
Jean Tourrilhes | 1 Oct 2003 01:00
Picon

Re: [PATCH] (0/16) intro to IRDA patches for 2.6.0-test6

On Tue, Sep 30, 2003 at 03:25:30PM -0700, Stephen Hemminger wrote:
> These patches are a replacement for the moderate one chunk I sent out yesterday.
> They continue in the same vein of revising how IRDA devices are allocated.
> The new thing is the introduction of alloc_irdadev and changing over the places
> I used alloc_netdev to that.
> 
> Mostly they are trivial, but smsc-ircc2 got changed to get rid of check_region
> usage as well.
> 
> David, please apply after Jean gives his approval.

	The self destruct patch is absolutely needed, and I like very
much the alloc_irdadev work.
	Please go ahead, I'll test them in parallel.
	Thanks !

	Jean
Permalink | Reply | 2 comments |
headers
Greg KH | 1 Oct 2003 01:32
Gravatar

Re: [PATCH 2.6] pci.ids for e1000

On Fri, Sep 12, 2003 at 09:07:17PM +0200, Xose Vazquez Perez wrote:
> Jeff Garzik wrote:
> 
> > The general idea is to keep 2.4, 2.6, and pciids.sf.net in sync.
> 
> is there sync between 2.4, 2.6, and pciids.sf.net ?  ;-)
> 
> Linus and Marcelo should not accept patches against pci.ids,
> all updates should go to pciids.sf.net. And every X time
> to do a sync with 2.4 and 2.6.

I'd love to see a volunteer to try to sync these files up and routinely
send updates to the pci maintainers of the different kernel trees.

Anyone?

I also agree with David, it's completly acceptable for drivers to add
their ids to this file when they are added to the kernel tree.

thanks,

greg k-h
Permalink | Reply | 0 comments |
headers
Martin Diehl | 1 Oct 2003 01:25
Picon

Re: [irda-users] Re: [PATCH] (0/16) intro to IRDA patches for 2.6.0-test6

On Tue, 30 Sep 2003, Jean Tourrilhes wrote:

> On Tue, Sep 30, 2003 at 03:25:30PM -0700, Stephen Hemminger wrote:
> > These patches are a replacement for the moderate one chunk I sent out yesterday.
> > They continue in the same vein of revising how IRDA devices are allocated.
> > The new thing is the introduction of alloc_irdadev and changing over the places
> > I used alloc_netdev to that.
> > 
> > Mostly they are trivial, but smsc-ircc2 got changed to get rid of check_region
> > usage as well.
> > 
> > David, please apply after Jean gives his approval.
> 
> 	The self destruct patch is absolutely needed, and I like very
> much the alloc_irdadev work.
> 	Please go ahead, I'll test them in parallel.
> 	Thanks !

I hadn't yet time for testing but since you were asking: I do also like 
the alloc_irdadev/free_netdev approach and the sir_dev part looks good to 
me, i.e. no leaking there. Thanks Stephen!

Martin
Permalink | Reply | 0 comments |
headers
David S. Miller | 1 Oct 2003 08:39
Picon
Favicon

Re: RFC: [2.6 patch] disallow modular IPv6

On Tue, 30 Sep 2003 12:04:31 -0300
Arnaldo Carvalho de Melo <acme <at> conectiva.com.br> wrote:

> And just for the record, as a matter of taste I'd like to see all #ifdefs in
> structs to disappear, look at what I did to struct sock in 2.5 and look at
> struct sock (include/net/sock.h) in 2.4: no #ifdefs where there was a ton,

I totally agree with this.  It would make the structs that actually
get used smaller in fact.
Permalink | Reply | 0 comments |
headers
David S. Miller | 1 Oct 2003 08:51
Picon
Favicon

Re: Fw: Badness in local_bh_enable at kernel/softirq.c:119

On Tue, 30 Sep 2003 10:27:08 -0700
"Feldman, Scott" <scott.feldman <at> intel.com> wrote:

> At this point, I'm leaning towards removing the offending code in the
> timer callback now, and taking a step back to solve the bigger problem,
> either with a better locking scheme, or a new plan on how to flush the
> "stuck" work.  We don't need kernel panics when you trip over the
> Ethernet cable!  Sound like a plan?

Why do you even need to use IRQ locking here?

Your e1000 netdev->hard_start_xmit method doesn't need to do anything
special, why does this timer code?  I suppose you need to synchronize
with e1000_clean_tx_irq() in the non-NAPI case right?  If so, that's
not being accomplished by what your code is doing.  If nobody else
takes that xmit_lock in an IRQ disabling manner, the e1000 timer code
doing so doesn't make any difference.

I have an idea for attacking the problem, once you figure out what
kind of locking you really need.  Do whatever you need to do to
synchronize on the hardware side, but instead of directly freeing
the SKB, add each one to a list.  A pointer to the head of this list
is stored on the stack of the timer routine, and passed down into
the TX purger.

Then at the top level you can drop all your locks, re-enable hw IRQs
and whatever else you need to do, then pass the SKBs in the list off
to dev_kfree_skb_irq() (this is the appropriate routine to call to
free an SKB from a timer handler, which runs in soft interrupt
context).
(Continue reading)

Permalink | Reply | 0 comments |
headers
David S. Miller | 1 Oct 2003 09:05
Picon
Favicon

Re: [Bonding-devel] Re: [bonding] compatibilty issues

On Tue, 30 Sep 2003 17:36:50 -0400
"Chad N. Tindel" <chad <at> tindel.net> wrote:

> My recommendations are more towards the middle than either end.  I would
> like to see us get rid of the _OLD ioctls in the 2.6 kernel specifically 
> because it uses the SIOCDEVPRIVATE ioctls.
 ...
> I would like to see them stay in 2.4 for the rest of the 2.4 tree
> specifically so that people who want to run on 3 year old systems
> can continue to do so without us breaking their world.

I think this is fine, personally.

I defer to Jeff for final judgment, he should be allowed to chime in
at least once more.
Permalink | Reply | 0 comments |
headers
David S. Miller | 1 Oct 2003 09:07
Picon
Favicon

Re: [PATCH] (0/16) intro to IRDA patches for 2.6.0-test6

On Tue, 30 Sep 2003 16:00:49 -0700
Jean Tourrilhes <jt <at> bougret.hpl.hp.com> wrote:

> On Tue, Sep 30, 2003 at 03:25:30PM -0700, Stephen Hemminger wrote:
> > David, please apply after Jean gives his approval.
 ...
> 	Please go ahead, I'll test them in parallel.
> 	Thanks !

Great, I'm applying Stephen's patches now.
Permalink | Reply | 0 comments |
headers
Florian Zwoch | 1 Oct 2003 10:02

Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction

issue seems to partly solved. the e1000 driver seems to be ok!
i reconfigured my kernel and intentionally left out netfilter options. 
after that my network performance was back to normal.

netfilter was only compiled in the kernel. it was not used with any rules!

so my wild guess would be that something with the netfilter code (i am 
not 100% sure it was netfilter.. _maybe_ it was some small odd kernel 
option i accidently enabled/disabled) is broken since test3 (again 
uncertified. but i firstly noticed this switching from test3 to test4).

Florian Zwoch wrote:
> hi,
> this has been discussed very roughly before. but unfortunately no real 
> solution has been brought up so far (or i have not read it yet).
> 
> problem in short: the 82540EM intel gigabit adapter became very slow as 
> of 2.6.0-test4. maybe earlier versions were als affected aswell, but i 
> noticed this behaviour on test4 and later. the 'slowness' of the adapter 
> only affects a certain data direction. i performed the following tests 
> to show you what is wrong.
> 
> dummy data file was 34257856 bytes (34.3MB).
> test machines were a pentium4 with the intel adapter, and a pentium2 266 
> with a lowcost realtek card (runs linux 2.4).
> 
> SCP:
>   e1000 -> 8139too    28.6KB/s
>   e1000 <- 8139too    4.6MB/s
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Feldman, Scott | 1 Oct 2003 10:19
Picon
Favicon

RE: Fw: Badness in local_bh_enable at kernel/softirq.c:119

> Why do you even need to use IRQ locking here?
> 
> Your e1000 netdev->hard_start_xmit method doesn't need to do 
> anything special, why does this timer code?  I suppose you 
> need to synchronize with e1000_clean_tx_irq() in the non-NAPI 
> case right?  If so, that's not being accomplished by what 
> your code is doing.  If nobody else takes that xmit_lock in 
> an IRQ disabling manner, the e1000 timer code doing so 
> doesn't make any difference.
> 
> I have an idea for attacking the problem, once you figure out 
> what kind of locking you really need.  Do whatever you need 
> to do to synchronize on the hardware side, but instead of 
> directly freeing the SKB, add each one to a list.  A pointer 
> to the head of this list is stored on the stack of the timer 
> routine, and passed down into the TX purger.
> 
> Then at the top level you can drop all your locks, re-enable 
> hw IRQs and whatever else you need to do, then pass the SKBs 
> in the list off to dev_kfree_skb_irq() (this is the 
> appropriate routine to call to free an SKB from a timer 
> handler, which runs in soft interrupt context).

Chris can jump in here anytime.  :-)

Synchronizing on the hardware side is stumping me.  We have the list of
skbs you describe, but I'm concerned about unmapping the skb buffers if
hardware is right in the middle of some DMA  on one of the buffers.
Some archs really don't like hardware accessing unmapped buffers.
(Continue reading)

Permalink | Reply | 752 comments |
headers
David S. Miller | 1 Oct 2003 10:37
Picon
Favicon

Re: Fw: Badness in local_bh_enable at kernel/softirq.c:119

On Wed, 1 Oct 2003 01:19:41 -0700
"Feldman, Scott" <scott.feldman <at> intel.com> wrote:

> Synchronizing on the hardware side is stumping me.  We have the list of
> skbs you describe, but I'm concerned about unmapping the skb buffers if
> hardware is right in the middle of some DMA  on one of the buffers.
> Some archs really don't like hardware accessing unmapped buffers.

Good point, if the e1000 accesses the DMA buffer after the unmap
it will cause many arch's to signal PCI errors since the IOMMU
will no longer have a valid translation for those DMA requests.

> Here's what I'm thinking: when link down is detected in the timer, just
> trick hardware into thinking link is still up (ILOS - Invert Loss of
> Signal).  No locking, no disabling of interrupts.  Hardware will do the
> natural thing by completing the outstanding sends and also provide the
> interrupts so we can clean/return skbs as normal (e1000_clean_tx_irq).

If you can make that work, it's the simplest fix.
Permalink | Reply | 0 comments |

Gmane