* RE: [PATCH] phy: export phy_mii_ioctl
From: Pedro Luis D. L. @ 2007-09-19 8:54 UTC (permalink / raw)
To: Jon Smirl, Domen Puncer; +Cc: netdev, linuxppc-embedded
In-Reply-To: <9e4733910709181229m4afe7ecr56e2411f52a84232@mail.gmail.com>
Hello Jon,
I´m also working with a Phytec pcm030, but I can´t get it booted...
Which kernel are you using?
I tried to apply the 7 bestcomm patches from Sylvain and patch over these with this new ones that Domen released.
The base kernel I´m using is 2.6.22.6 from kernel.org.
Although I used the patch that creates pcm030.c in arch/platforms/52xx/ and compiled using this file, it gets halted at booting time.
Bytes transferred = 5091 (13e3 hex)
## Booting image at 00500000 ...
Image Name: Linux-2.6.22.6
Created: 2007-09-19 8:53:02 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1196911 Bytes = 1.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x400000
(No more output and boot is halted)
Are you using any other patch for the platform or any other kernel, because I tried to apply these patches to a 2.6.20 kernel and are not successful.
Bests,
Pedro.
> Date: Tue, 18 Sep 2007 15:29:09 -0400> From: jonsmirl@gmail.com
> To: domen@coderock.org> Subject: Re: [PATCH] phy: export phy_mii_ioctl
> CC: netdev@vger.kernel.org; linuxppc-embedded@ozlabs.org
>> On 9/18/07, Domen Puncer wrote:
>> More testing and getting it to work properly on Phytec pcm030 would
>> be great.>> Do we want to do anything about this?
>> [ 1.569657] net eth0: attached phy 0 to driver Generic PHY
> [ 2.576013] Sending DHCP requests .PHY: f0003000:00 - Link is Up
> - 100/Full> [ 4.612000] ., OK
> [ 6.764005] IP-Config: Got DHCP answer from 192.168.1.200, my
> address is 192.168.1.5
>> What is happening is the printk for "PHY: f0003000:00 - Link is Up
> - 100/Full" is done in an interrupt and it comes in the middle of the> kernel doing DHCP and printing ... without a CR.
>> Two possible solutions, get rid of the link-up message or wait in in
> the initial driver load until the link is up. Or we could leave it the
> way it is, but some people may report this as a bug.
>>> --> Jon Smirl> jonsmirl@gmail.com
> _______________________________________________
> Linuxppc-embedded mailing list> Linuxppc-embedded@ozlabs.org> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Busca desde cualquier página Web con una protección excepcional. Consigue la Barra de herramientas de Windows Live hoy mismo y GRATUITAMENTE.
http://www.toolbar.live.com
^ permalink raw reply
* Re: [RFC] af_packet: allow disabling timestamps
From: Evgeniy Polyakov @ 2007-09-19 9:07 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, Unai Uribarri, David S. Miller, netdev
In-Reply-To: <20070914122642.5343b128@oldman>
On Fri, Sep 14, 2007 at 12:26:42PM +0200, Stephen Hemminger (shemminger@linux-foundation.org) wrote:
> No, then we end up timestamping all the packets, even if they get dropped by
> packet filter. The change in 2.6.24 allows dhclient (and rstp) to only call
> hires clock source for packets they want, not all packets.
>
> Perhaps the timestamping needs to change into a tristate flag?
Sorry for late reply - the situation we need to workaround (if I
uderstood correctly) is to disable timestamp when there are packet
sockets. Why tristate flag should ever be used?
--
Evgeniy Polyakov
^ permalink raw reply
* Info about updates
From: Sergej Stepanov @ 2007-09-19 8:53 UTC (permalink / raw)
To: netdev
Hello list.
For our embedded platform i wrote the driver for micrel phy and integrated it into drivers/net/phy.
I need general information about how do i send the patch to the netdev-list.
Thanks for any advice and sorry.
Best regards
Sergej.
--
Sergej I. Stepanov
IDS GmbH
Nobelstr. 18, Zim. 2.1.05
D-76275 Ettlingen
T +49 (0) 72 43/2 18-615
F +49 (0) 72 43/2 18-400
http://www.ids.de
Email: Sergej.Stepanov@ids.de
^ permalink raw reply
* Re: SFQ qdisc crashes with limit of 2 packets
From: Alexey Kuznetsov @ 2007-09-19 9:48 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Chuck Ebbert, Netdev
In-Reply-To: <46F023D0.7030307@trash.net>
Hello!
> OK the off-by-one prevents an out-of-bounds array access,
Yes, this is not off-by-one (off-by-two, to be more exact :-)).
Maximal queue length is really limited by SFQ_DEPTH-2, because:
1. SFQ keeps list of queue lengths in array of length SFQ_DEPTH.
This means length of queue must be in range 0..SFQ_DEPTH-1.
2. SFQ enqueues incoming packet first, and drops something after this.
This means it always needs a free slot in queue. So, SFQ_DEPTH-2.
> CCed Alexey just to be safe, but I think the patch should be fine.
Yes. But what'a about limit == 1? tc prohibits this case, but it is still
not nice to have the bug in kernel. Plus, code remains creepy, the check
+ if (++sch->q.qlen < q->limit) {
still looks as a scary off-by-one. I would go all the way: replace this
with natural:
if (++sch->q.qlen <= q->limit) {
and maxed q->limit at SFQ_DEPTH-2. Patch enclosed.
Seems, it is easy to relax the limit to SFQ_DEPTH-1, item #2 is an artificial
limitation. If current queue already has SFQ_DEPTH-1 packets, we can
drop from tail of this queue and skip update of all the state. It is even
an optimization for the case when we have single flow. I am not 100% sure
about this, I'll try and report.
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 9579573..cbf8089 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -270,7 +270,7 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc* sch)
q->tail = x;
}
}
- if (++sch->q.qlen < q->limit-1) {
+ if (++sch->q.qlen <= q->limit) {
sch->bstats.bytes += skb->len;
sch->bstats.packets++;
return 0;
@@ -306,7 +306,7 @@ sfq_requeue(struct sk_buff *skb, struct Qdisc* sch)
q->tail = x;
}
}
- if (++sch->q.qlen < q->limit - 1) {
+ if (++sch->q.qlen <= q->limit) {
sch->qstats.requeues++;
return 0;
}
@@ -391,10 +391,10 @@ static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
q->quantum = ctl->quantum ? : psched_mtu(sch->dev);
q->perturb_period = ctl->perturb_period*HZ;
if (ctl->limit)
- q->limit = min_t(u32, ctl->limit, SFQ_DEPTH);
+ q->limit = min_t(u32, ctl->limit, SFQ_DEPTH - 2);
qlen = sch->q.qlen;
- while (sch->q.qlen >= q->limit-1)
+ while (sch->q.qlen > q->limit)
sfq_drop(sch);
qdisc_tree_decrease_qlen(sch, qlen - sch->q.qlen);
@@ -423,7 +423,7 @@ static int sfq_init(struct Qdisc *sch, struct rtattr *opt)
q->dep[i+SFQ_DEPTH].next = i+SFQ_DEPTH;
q->dep[i+SFQ_DEPTH].prev = i+SFQ_DEPTH;
}
- q->limit = SFQ_DEPTH;
+ q->limit = SFQ_DEPTH - 2;
q->max_depth = 0;
q->tail = SFQ_DEPTH;
if (opt == NULL) {
^ permalink raw reply related
* Re: Please pull 'iwlwifi' branch of wireless-2.6
From: Christoph Hellwig @ 2007-09-19 10:13 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, jeff, netdev, linux-wireless
In-Reply-To: <20070918185040.GF4940@tuxdriver.com>
On Tue, Sep 18, 2007 at 02:50:40PM -0400, John W. Linville wrote:
> Jeff & Dave,
>
> Here it is -- it's big, it's...well...beautiful in its own way...well,
> at least it seems to work... :-)
>
> There are some outstanding issues. The driver does more than it
> probably should under the covers instead of in the stack, and the
> issue of including headers with a "../../mac80211/..." path remains.
> Still, I think it would be better to get this mainlined than to keep
> it out of stream.
it really needs to be moved into a directory of it's own.
The useless per-file CFLAGS need to go most places can trivially
be made unconditional anyway.
The depends on m for CONFIG_IWL4965 and CONFIG_IWL3945 needs to go,
we don't put drivers int that need to be modular.
This is just a tiny review from the build system point of view.
>
> Thanks!
>
> John
>
> ---
>
> Patch available here:
>
> http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/iwlwifi/0001-iwlwifi-add-iwlwifi-wireless-drivers.patch
>
> ---
>
> The following changes since commit 0d4cbb5e7f60b2f1a4d8b7f6ea4cc264262c7a01:
> Linus Torvalds (1):
> Linux 2.6.23-rc6
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git iwlwifi
>
> Zhu Yi (1):
> iwlwifi: add iwlwifi wireless drivers
>
> MAINTAINERS | 9 +
> drivers/net/wireless/Kconfig | 129 +
> drivers/net/wireless/Makefile | 12 +
> drivers/net/wireless/iwl-3945-hw.h | 118 +
> drivers/net/wireless/iwl-3945-rs.c | 979 ++++
> drivers/net/wireless/iwl-3945-rs.h | 191 +
> drivers/net/wireless/iwl-3945.c | 2290 +++++++++
> drivers/net/wireless/iwl-3945.h | 41 +
> drivers/net/wireless/iwl-4965-hw.h | 581 +++
> drivers/net/wireless/iwl-4965-rs.c | 2118 ++++++++
> drivers/net/wireless/iwl-4965-rs.h | 266 +
> drivers/net/wireless/iwl-4965.c | 4719 ++++++++++++++++++
> drivers/net/wireless/iwl-4965.h | 341 ++
> drivers/net/wireless/iwl-channel.h | 161 +
> drivers/net/wireless/iwl-commands.h | 1734 +++++++
> drivers/net/wireless/iwl-debug.h | 149 +
> drivers/net/wireless/iwl-eeprom.h | 336 ++
> drivers/net/wireless/iwl-helpers.h | 255 +
> drivers/net/wireless/iwl-hw.h | 537 ++
> drivers/net/wireless/iwl-io.h | 470 ++
> drivers/net/wireless/iwl-priv.h | 308 ++
> drivers/net/wireless/iwl-prph.h | 229 +
> drivers/net/wireless/iwl-spectrum.h | 91 +
> drivers/net/wireless/iwl3945-base.c | 8732 ++++++++++++++++++++++++++++++++
> drivers/net/wireless/iwl4965-base.c | 9323 +++++++++++++++++++++++++++++++++++
> drivers/net/wireless/iwlwifi.h | 713 +++
> 26 files changed, 34832 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/wireless/iwl-3945-hw.h
> create mode 100644 drivers/net/wireless/iwl-3945-rs.c
> create mode 100644 drivers/net/wireless/iwl-3945-rs.h
> create mode 100644 drivers/net/wireless/iwl-3945.c
> create mode 100644 drivers/net/wireless/iwl-3945.h
> create mode 100644 drivers/net/wireless/iwl-4965-hw.h
> create mode 100644 drivers/net/wireless/iwl-4965-rs.c
> create mode 100644 drivers/net/wireless/iwl-4965-rs.h
> create mode 100644 drivers/net/wireless/iwl-4965.c
> create mode 100644 drivers/net/wireless/iwl-4965.h
> create mode 100644 drivers/net/wireless/iwl-channel.h
> create mode 100644 drivers/net/wireless/iwl-commands.h
> create mode 100644 drivers/net/wireless/iwl-debug.h
> create mode 100644 drivers/net/wireless/iwl-eeprom.h
> create mode 100644 drivers/net/wireless/iwl-helpers.h
> create mode 100644 drivers/net/wireless/iwl-hw.h
> create mode 100644 drivers/net/wireless/iwl-io.h
> create mode 100644 drivers/net/wireless/iwl-priv.h
> create mode 100644 drivers/net/wireless/iwl-prph.h
> create mode 100644 drivers/net/wireless/iwl-spectrum.h
> create mode 100644 drivers/net/wireless/iwl3945-base.c
> create mode 100644 drivers/net/wireless/iwl4965-base.c
> create mode 100644 drivers/net/wireless/iwlwifi.h
> --
> John W. Linville
> linville@tuxdriver.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---end quoted text---
^ permalink raw reply
* Re: [PATCH] phy: export phy_mii_ioctl
From: Juergen Beisert @ 2007-09-19 10:37 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Pedro Luis D. L., Jon Smirl, Domen Puncer, netdev
In-Reply-To: <BLU106-W49D16A32DDFE2611E15371CAB90@phx.gbl>
Pedro,
On Wednesday 19 September 2007 10:54, Pedro Luis D. L. wrote:
> I´m also working with a Phytec pcm030, but I can´t get it booted...
> Which kernel are you using?
> I tried to apply the 7 bestcomm patches from Sylvain and patch over these
> with this new ones that Domen released. The base kernel I´m using is
> 2.6.22.6 from kernel.org.
> Although I used the patch that creates pcm030.c in arch/platforms/52xx/ and
> compiled using this file, it gets halted at booting time.
>
> Bytes transferred = 5091 (13e3 hex)
> ## Booting image at 00500000 ...
> Image Name: Linux-2.6.22.6
> Created: 2007-09-19 8:53:02 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1196911 Bytes = 1.1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using flat device tree at 0x400000
>
> (No more output and boot is halted)
Check your oftree! Most of the time this behaviour means its a wrong oftree in
use.
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* RE: [PATCH] tehuti: driver for Tehuti 10GbE network adapters
From: Alexander Indenbaum @ 2007-09-19 10:44 UTC (permalink / raw)
To: 'Christoph Hellwig'
Cc: jeff, davem, akpm, netdev, 'Nadav Shemer',
'Andy Gospodarek'
In-Reply-To: <20070918094723.GA2539@infradead.org>
Christoph,
Thank you for reviewing the driver and giving us this feedback. Our goal is
the driver which is in full accordance with all Linux kernel style
guidelines. Please note the fist Tehuti driver submission to netdev was by
Andy on Mars 15 and since the driver has been heavily re-factored based on
Jeff's suggestions. I agree with most of your style remarks and we'll
release the patch soon.
Meanwhile let me ask clarification about two of your remarks bellow that I'm
not sure I fully understand.
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Tuesday, September 18, 2007 11:47 AM
> To: Andy Gospodarek
> Cc: jeff@garzik.org; davem@davemloft.org; akpm@linux-foundation.org;
> netdev@vger.kernel.org; baum@tehutinetworks.net
> Subject: Re: [PATCH] tehuti: driver for Tehuti 10GbE network adapters
>
>
> Some comment from looking at the driver in the -mm tree:
>
> - please kill the CPU_CHIP_SWAP macros and use the normal linux
> cpu_to_le*/le*_to_cpu and verify them using sparse.
> See Documentation/sparse.txt on how to do that
> - please include the linux header in the .c file, not the .h
> - please don't redefine the dma mask constants
> - please use the firmware loader instead of mebedding a firmware
> image
Could you give us some pointers to docs and examples of "firmware loader"?
I'm not sure I'm familiar with such mechanism in Linux kernel.
> - please don't invent your own debugging macros but use
> dev_dbg and friends
> - please kill the ENTER/RET macros
> - please kill BDX_ASSERT
> - the unregister_netdev directly followed by free_netdev in
> bdx_remove look buggy, but I'm not entirely sure how to handle
> multi-port devices properly here.
Putting dual-port issue aside, could you elaborate what is the problem in
your opinion in bdx_remove() implementation? What is wrong with calling
free_netdev() right after unregister_netdev()? Could you provide pointers
for docs and examples to correct PCI network device remove interface
implementation?
> - please declare bdx_ethtool_ops on file-scope and kill
> bdx_ethtool_ops
> - please don't put assignments into conditionals ala
>
> if ((err = pci_request_regions(pdev, BDX_DRV_NAME)))
> goto err_dma;
>
> but rather write
>
> err = pci_request_regions(pdev, BDX_DRV_NAME);
> if (err)
> goto err_dma;
Thank you again for your help,
Alexander Indenbaum
^ permalink raw reply
* Re: Please pull 'b43' branch of wireless-2.6
From: Johannes Berg @ 2007-09-19 10:54 UTC (permalink / raw)
To: John W. Linville
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, jeff-o2qLIJkoznsdnm+yROfE0A,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, sam-uyr5N9Q2VtJg9hUCZPvPmw
In-Reply-To: <20070918202819.GI4940-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 250 bytes --]
On Tue, 2007-09-18 at 16:28 -0400, John W. Linville wrote:
> This series adds the b43 and b43legacy drivers, as well as the ssb
> bus infrastructure upon which they depend.
Shouldn't we be getting rid of bcm43xx at the same time?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH v2] iw_cxgb3: Support "iwarp-only" interfaces to avoid 4-tuple conflicts.
From: Evgeniy Polyakov @ 2007-09-19 10:56 UTC (permalink / raw)
To: Steve Wise; +Cc: rdreier, sean.hefty, netdev, linux-kernel, general
In-Reply-To: <46EE9C50.7070406@opengridcomputing.com>
Hi Steve.
On Mon, Sep 17, 2007 at 10:25:04AM -0500, Steve Wise (swise@opengridcomputing.com) wrote:
> >Does creating the whole new netdevice is a too big overhead, or is it
> >considered bad idea?
>
> I think its too big overhead, and pretty invasive on the low level cxgb3
> driver. I think having a device in the 'ifconfig -a' after iw_cxgb3 is
> loaded and devices discovered would be a good thing for the admin. This
> is the angle Roland suggested. I'm just not sure how to implement it.
>
> But if someone could explain how I might create this full netdevice as a
> pseudo device on top of the real one, maybe I could implement it.
>
> Note that non TCP traffic still needs to utilize this interface for ND
> to work properly with the RDMA core.
Just a though - what about allowing secondary addresses with the same
address as main one? I.e. change bit of the core code to allow creating
aliases with the same address as main device, so that you would be able
to create ':iw' alias during rdma device initialization?
If this solution is not acceptible, then I belive your alias change is
the way to go.
--
Evgeniy Polyakov
^ permalink raw reply
* [patch 0/1] s390 maintainer change
From: Ursula Braun @ 2007-09-19 11:09 UTC (permalink / raw)
To: davem, jgarzik, akpm, netdev, linux-s390
--
Please update MAINTAINERS file because of changes in the s390 networking team
Regards, Ursula Braun
^ permalink raw reply
* [patch 1/1] From: Ursula Braun <braunu@de.ibm.com>
From: Ursula Braun @ 2007-09-19 11:09 UTC (permalink / raw)
To: davem, jgarzik, akpm, netdev, linux-s390
In-Reply-To: <20070919110901.080242000@linux.vnet.ibm.com>
[-- Attachment #1: s390-MAINTAINERS.diff --]
[-- Type: text/plain, Size: 1127 bytes --]
[PATCH] s390 MAINTAINERS
maintainer change for s390 networking
Signed-off-by: Ursula Braun <braunu@de.ibm.com>
---
MAINTAINERS | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
===================================================================
Index: net-2.6-uschi/MAINTAINERS
===================================================================
--- net-2.6-uschi.orig/MAINTAINERS
+++ net-2.6-uschi/MAINTAINERS
@@ -3056,8 +3056,8 @@ W: http://www.ibm.com/developerworks/lin
S: Supported
S390 NETWORK DRIVERS
-P: Frank Pavlic
-M: fpavlic@de.ibm.com
+P: Ursula Braun
+M: ubraun@linux.vnet.ibm.com
M: linux390@de.ibm.com
L: linux-s390@vger.kernel.org
W: http://www.ibm.com/developerworks/linux/linux390/
@@ -3071,6 +3071,14 @@ L: linux-s390@vger.kernel.org
W: http://www.ibm.com/developerworks/linux/linux390/
S: Supported
+S390 IUCV NETWORK LAYER
+P: Ursula Braun
+M: ubraun@linux.vnet.ibm.com
+M: linux390@de.ibm.com
+L: linux-s390@vger.kernel.org
+W: http://www.ibm.com/developerworks/linux/linux390/
+S: Supported
+
SAA7146 VIDEO4LINUX-2 DRIVER
P: Michael Hunold
M: michael@mihu.de
--
^ permalink raw reply
* [Bug, PATCH and another Bug] Was: Fix refcounting problem with netif_rx_reschedule()
From: Krishna Kumar @ 2007-09-19 11:54 UTC (permalink / raw)
To: davem; +Cc: netdev, rdreier, general, Krishna Kumar
Hi Dave,
After applying Roland's NAPI patch, system panics when I run multiple
thread iperf (no stack trace at this time, it shows that the panic is in
net_tx_action).
I think the problem is:
In the "done < budget" case, ipoib_poll calls netif_rx_complete()
netif_rx_complete()
__netif_rx_complete()
__napi_complete()
list_del()
__list_del()
entry->next = LIST_POISON1;
entry->prev = LIST_POISON2;
Due to race with another completion (explained at end of the patch),
net_rx_action finds quota==0 (even though done < budget earlier):
net_rx_action()
if (unlikely(!n->quota)) {
n->quota = n->weight;
list_move_tail()
__list_del(POISON, POISON)
<PANIC>
}
while IPoIB calling netif_rx_reschedule() works fine due to:
netif_rx_reschedule
__netif_rx_schedule
__napi_schedule
list_add_tail (this is OK)
Patch that fixes this:
diff -ruNp a/include/linux/netdevice.h b/include/linux/netdevice.h
--- a/include/linux/netdevice.h 2007-09-19 16:50:35.000000000 +0530
+++ b/include/linux/netdevice.h 2007-09-19 16:51:28.000000000 +0530
@@ -346,7 +346,7 @@ static inline void napi_schedule(struct
static inline void __napi_complete(struct napi_struct *n)
{
BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
- list_del(&n->poll_list);
+ __list_del(&n->poll_list);
smp_mb__before_clear_bit();
clear_bit(NAPI_STATE_SCHED, &n->state);
}
When I apply this patch, things work fine but I get napi_check_quota_bug()
warning. This race seems to happen as follows:
CPU#1: ipoib_poll(budget=100)
{
A. process 100 skbs
B. netif_rx_complete()
<Process unrelated interrupts; executes slower than steps C, D, E on
CPU#2>
F. ib_req_notify_cq() (no missed completions, do nothing)
G. return 100
H. return to net_rx_action, quota=99, subtract 100, quota=-1, BUG.
}
CPU#2: ipoib_ib_completion() : (starts and finishes entire line of execution
*after* step B and *before* H executes).
{
C. New skb comes, call netif_rx_schedule; set quota=100
D. do ipoib_poll(), process one skb, return work=1 to net_rx_action
E. net_rx_action: set quota=99
}
The reason why both cpu's can execute poll simultaneously is because
netpoll_poll_lock() returns NULL (dev->npinfo == NULL). This results in
negative napi refcount and the warning. I verified this is the reason by
saving the original quota before calling poll (in net_tx_action) and
comparing with final after poll (before it gets updated), and it gets
changed very often in multiple thread testing (atleast 4 threads, haven't
seen with 2). In most cases, the quota becomes -1, and I have seen upto
-9 but those are rarer.
Note: during steps F-H and C-E, priv/napi is read/modified by both cpu's
which is another bug relating to the same race.
I guess the above patch is not required if this bug (in IPoIB) is fixed?
Roland, why cannot we get rid of "poll_more" ? We will get called again
after netif_rx_reschedule, and it is cleaner to let the new execution handle
fresh completions. Is there a reason why this goto is required?
Thanks,
- KK
^ permalink raw reply
* Re: [0/7] [PPP]: Fix shared/cloned/non-linear skb bugs (was: malformed captured packets)
From: Herbert Xu @ 2007-09-19 11:51 UTC (permalink / raw)
To: Toralf Förster; +Cc: netdev, Paul Mackerras, James Chapman
In-Reply-To: <200709112012.53165.toralf.foerster@gmx.de>
On Tue, Sep 11, 2007 at 08:12:50PM +0200, Toralf Förster wrote:
>
> I'm wondering why some UDP packets of the MS messenger protocol (with the usual
> text like "please click at www.we-destroy-your-computer.com") always have wrong
> check sums regardless whether sniffed at ppp0 or eth0 interface.
Maybe your wireshark is broken? I've tried wireshark and tcpdump
here and the sums look fine.
> and I'm wondering why it is still possible to capture such packets at eth0.
tcpdump happens before the packet goes into the IP stack which
is whare iptables lives.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] phy: export phy_mii_ioctl
From: Domen Puncer @ 2007-09-19 11:56 UTC (permalink / raw)
To: Jon Smirl; +Cc: netdev, linuxppc-embedded, sven
In-Reply-To: <9e4733910709181217v417438s85bb9e6b4ad4b475@mail.gmail.com>
On 18/09/07 15:17 -0400, Jon Smirl wrote:
> On 9/18/07, Domen Puncer <domen@coderock.org> wrote:
> > More testing and getting it to work properly on Phytec pcm030 would
> > be great.
>
> I compiled it as a module:
> CC [M] drivers/net/fec_mpc52xx/fec.o
> drivers/net/fec_mpc52xx/fec.c:613: warning: 'mpc52xx_fec_mac_setup'
> defined but not used
>
> This code needs to be enclosed in "#ifndef MODULE". But why aren't you
> using module_param() to make a string parameter and then copy it into
> mpc52xx_fec_mac_addr[] if the parameter is not null?
Right,
Patch at the end.
When compiled as module use "modprobe fec_mpc52xx mac=foo",
when built-in add to boot line: "fec_mpc52xx.mac=foo"
As for link-up-printk in the middle of DHCP requests...
is it really that big of a problem?
This sort of things happen when printk doesn't have the whole
line... getting rid of link-up message would just hide it (it can show
ie. when an usb device is bound to scsi layer).
Domen
---
drivers/net/fec_mpc52xx/fec.c | 18 ++----------------
1 files changed, 2 insertions(+), 16 deletions(-)
Index: linux.git/drivers/net/fec_mpc52xx/fec.c
===================================================================
--- linux.git.orig/drivers/net/fec_mpc52xx/fec.c
+++ linux.git/drivers/net/fec_mpc52xx/fec.c
@@ -53,6 +53,8 @@ static void fec_start(struct net_device
static void fec_reset(struct net_device *dev);
static u8 mpc52xx_fec_mac_addr[6];
+module_param_array_named(mac, mpc52xx_fec_mac_addr, byte, NULL, 0);
+MODULE_PARM_DESC(mac, "six hex digits, ie. 0x1,0x2,0xc0,0x01,0xba,0xbe");
static void fec_tx_timeout(struct net_device *dev)
{
@@ -609,22 +611,6 @@ static void fec_set_multicast_list(struc
}
}
-static int __init mpc52xx_fec_mac_setup(char *mac_address)
-{
- int i;
- u64 val64;
-
- val64 = simple_strtoull(mac_address, NULL, 16);
-
- for (i = 0; i < 6; i++)
- mpc52xx_fec_mac_addr[5-i] = val64 >> (i*8);
-
- return 0;
-}
-
-__setup("mpc52xx-mac=",mpc52xx_fec_mac_setup);
-
-
/**
* fec_hw_init
* @dev: network device
^ permalink raw reply
* [PATCH] smc91x Hitachi Solution Engine (SuperH) Support
From: Nobuhiro Iwamatsu @ 2007-09-19 12:07 UTC (permalink / raw)
To: netdev; +Cc: nico, iwamatsu
Hi, all.
This patch supports Hitachi Solution Engine (SuperH) of smc91x.
Please apply this patch .
regards,
Nobuhiro
--
Nobuhiro Iwamatsu
E-Mail : iwamatsu@nigauri.org
GPG ID : 3170EBE9
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
index 6ff3a16..af9e6bf 100644
--- a/drivers/net/smc91x.h
+++ b/drivers/net/smc91x.h
@@ -284,6 +284,7 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
#elif defined(CONFIG_SUPERH)
#ifdef CONFIG_SOLUTION_ENGINE
+#define SMC_IRQ_FLAGS (0)
#define SMC_CAN_USE_8BIT 0
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 0
^ permalink raw reply related
* Re: wrong arp query with policy routing
From: Marco Berizzi @ 2007-09-19 13:04 UTC (permalink / raw)
To: netdev
In-Reply-To: <BAY103-DAV2BC129A14C4A29986CC0CB2B80@phx.gbl>
Marco Berizzi wrote:
> HDSL.225 dev eth0 scope link
> ADSL.129 dev eth0 scope link src ADSL.134
> ADSL.128/29 dev eth1 proto kernel scope link src ADSL.134
> HDSL.224/27 dev eth1 proto kernel scope link src HDSL.254
> 127.0.0.0/8 dev lo scope link
> default via HDSL.225 dev eth0 metric 1
> Chain OUTPUT (policy ACCEPT 2476380 packets, 1183993024 bytes)
> pkts bytes target prot opt in out source
> destination
> 61064 8582064 MARK tcp -- * * 0.0.0.0/0
> !172.16.0.0/12 multiport dports
> 20,21,80,123,443,2080,8080,8201,10000,8102,1443,81 MARK set 0x1
Me again.
When this box try to open a connection to
www.google.com:80 (for example), it send an
arp request like this:
15:12:38.246096 00:30:05:cb:27:c1 > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 42: arp who-has ADSL.129 tell HDSL.254
^^^^^^^^^^^^^
and the ISP managed cisco 877 router ignore
it, because the ip source address is from a
different network (should be ADSL.134 instead
of HDSL.254). Is this an expected behaviour
from linux?
Is there a way to force linux to make an arp
probe with the source ip belonging to the
same subnet requesting ip?
This is the 'ip ru sh' output:
0: from all lookup local
400: from all fwmark 0x1 lookup adsl
32766: from all lookup main
32767: from all lookup default
TIA
^ permalink raw reply
* Re: [LARTC] ifb and ppp
From: Patrick McHardy @ 2007-09-19 13:04 UTC (permalink / raw)
To: Frithjof Hammer; +Cc: lartc, Linux Netdev List
In-Reply-To: <200709191417.43768.mail@frithjof-hammer.de>
[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]
Frithjof Hammer wrote:
> My goal is to setup an ingress traffic shaping on my PPPOE DSL line with ifb.
>
> My old imq stuff used iptables marks (like 'iptables -t mangle -A
> PREROUTING -p tcp --sport 22 -m length --length :500 -j MARK --set-mark 31')
> to classify the traffic and since i am lazy, i tried to to reuse them with
> ifb. But no luck: iptables marks the packets well, but tc doesn't see the
> marks on ifb0.
>
> May be my problem is somewhere between ppp0 and ifb0, so for a basic test, I
> tried this:
>
> tc qdisc add dev ppp0 ingress
> modprobe ifb
> ip link set up dev ifb0
> tc filter add dev ppp0 parent ffff: protocol ip prio 10 u32 \
> match u32 0 0 flowid 1:1 \
> action mirred egress redirect dev ifb0
>
> and run:
>
> root@router:/# tcpdump -i ifb0 -n
> tcpdump: WARNING: ifb0: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ifb0, link-type EN10MB (Ethernet), capture size 96 bytes
> 12:38:29.584451 PPPoE [ses 0x7dc] IP 217.10.79.2.10000 > 84.189.95.184.1024:
> UDP, length 84
> 12:38:29.585924 PPPoE [ses 0x7dc] IP 84.189.5.17 > 84.189.95.184: GREv1, call
> 24388, seq 1868, ack 3210, length 205: compressed PPP data
> 12:38:29.600506 PPPoE [ses 0x7dc] IP truncated-ip - 256 bytes missing!
> 24.163.113.160.34247 > 84.189.95.184.9025: UDP, length 359
> [...]
>
> Looks like the packetes are still pppoe en-capsuled. Is this the correct
> behavior? This only occurs on ppp0, on other devices (like eth0) my iptables
> marks are matched by tc. What can I do to get my iptables marks working on
> ppp0 again?
Does this patch help?
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 365 bytes --]
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 5795789..7c80f16 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -83,6 +83,7 @@ static int tcf_mirred_init(struct rtattr *rta, struct rtattr *est,
case ARPHRD_IPGRE:
case ARPHRD_VOID:
case ARPHRD_NONE:
+ case ARPHRD_PPP:
ok_push = 0;
break;
default:
^ permalink raw reply related
* Re: SFQ qdisc crashes with limit of 2 packets
From: Patrick McHardy @ 2007-09-19 13:08 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: Chuck Ebbert, Netdev
In-Reply-To: <20070919094803.GA17740@ms2.inr.ac.ru>
Alexey Kuznetsov wrote:
> Hello!
>
>>CCed Alexey just to be safe, but I think the patch should be fine.
>
>
> Yes. But what'a about limit == 1? tc prohibits this case, but it is still
> not nice to have the bug in kernel. Plus, code remains creepy, the check
>
> + if (++sch->q.qlen < q->limit) {
>
> still looks as a scary off-by-one. I would go all the way: replace this
> with natural:
>
> if (++sch->q.qlen <= q->limit) {
>
> and maxed q->limit at SFQ_DEPTH-2. Patch enclosed.
Thats even better, thanks :)
^ permalink raw reply
* Re: [Bug, PATCH and another Bug] Was: Fix refcounting problem with netif_rx_reschedule()
From: Jan-Bernd Themann @ 2007-09-19 13:23 UTC (permalink / raw)
To: Krishna Kumar; +Cc: davem, netdev, rdreier, general, Christoph Raisch
In-Reply-To: <20070919115403.19455.65941.sendpatchset@K50wks273871wss.in.ibm.com>
Hi,
On Wednesday 19 September 2007 13:54, Krishna Kumar wrote:
> CPU#1: ipoib_poll(budget=100)
> {
> A. process 100 skbs
> B. netif_rx_complete()
> <Process unrelated interrupts; executes slower than steps C, D, E on
> CPU#2>
> F. ib_req_notify_cq() (no missed completions, do nothing)
> G. return 100
> H. return to net_rx_action, quota=99, subtract 100, quota=-1, BUG.
> }
>
> CPU#2: ipoib_ib_completion() : (starts and finishes entire line of execution
> *after* step B and *before* H executes).
> {
> C. New skb comes, call netif_rx_schedule; set quota=100
> D. do ipoib_poll(), process one skb, return work=1 to net_rx_action
> E. net_rx_action: set quota=99
> }
If I understood it right the problem you describe (quota update in
__napi_schdule) can cause further problems when you choose the
following numbers:
CPU1: A. process 99 pkts
CPU1: B. netif_rx_complete()
CPU2: interrupt occures, netif_rx_schedule is called, net_rx_action triggerd:
CPU2: C. set quota = 100 (__napi_schedule)
CPU2: D. call poll(), process 1 pkt
CPU2: D.2 call netif_rx_complete() (quota not exeeded)
CPU2: E. net_rx_action: set quota=99
CPU1: F. net_rx_action: set qutoa=99 - 99 = 0
CPU1: G. modify list (list_move_tail) altough netif_rx_complete has been called
Step G would fail as the device is not in the list due
to netif_rx_complete. This case can occur for all
devices running on an SMP system where interrupts are not pinned.
Regards,
Jan-Bernd
^ permalink raw reply
* Re: Please pull 'iwlwifi' branch of wireless-2.6
From: Jeff Garzik @ 2007-09-19 13:28 UTC (permalink / raw)
To: David Miller
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070918.122258.82101397.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller wrote:
> Jeff, if you have no objections I'll pull this into net-2.6.24
Given that there is now a large backlog of new drivers to review, I
think the preferred course of action would be to queue them into -mm
(via net-2.6.24) for wider review and testing, and then make sure they
all get a thorough review+ACK before pushing upstream.
So far, its sounding like each review has turned up stuff that wants
fixing before the drivers commented upon go upstream.
Jeff
^ permalink raw reply
* Re: [RFC][NET_SCHED] explict hold dev tx lock
From: jamal @ 2007-09-19 13:33 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, kaber, dada1, johnpol
In-Reply-To: <1190083728.4237.59.camel@localhost>
On Mon, 2007-17-09 at 22:48 -0400, jamal wrote:
> Nothing much has changed from what it was before.
> The only difference is we let go of the queue lock before grabbing
> the tx lock which never mattered for LLTX.
> Once we grab the tx lock it is the same logic and so far is working well
> on both tg3 and e1000 (which is LLTX).
> I will continue to retest with net-2.6.24 once you complete rebasing
> and look around to see if anyone maybe affected.
Ok, this is looking solid with this mornings tree. Tested on a dual core
xeon with e1000 (LLTX) and a dual core opteron with tg3 (non-LLTX).
About 100 million packets from udp full throttle on all 4 cpus; i tried
pulling cables etc while doing this to generate extrenous interupts and
didnt see any issues.
Shall i submit the patch?
cheers,
jamal
^ permalink raw reply
* Re: bnx2 dirver's firmware images
From: Bill Davidsen @ 2007-09-19 13:40 UTC (permalink / raw)
To: David Miller; +Cc: mchan, vda.linux, linux-kernel, netdev
In-Reply-To: <20070918.122150.124083496.davem@davemloft.net>
David Miller wrote:
> From: "Michael Chan" <mchan@broadcom.com>
> Date: Tue, 18 Sep 2007 13:05:51 -0700
>
>> The bnx2 firmware changes quite frequently. A new driver quite often
>> requires new firmware to work correctly. Splitting them up makes things
>> difficult for the user.
>>
>> The firmware in tg3 is a lot more mature and I don't expect it to
>> change. I think tg3 is better suited for using request_firmware().
>
> Like I said, I think neither should change and the driver should
> be fully functional when built statically into the kernel.
>
Is that a suggestion that the driver work differently when built as a
module or built in? I've seen that behavior many time over the years,
but it usually not deliberate. ;-)
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
^ permalink raw reply
* Re: [PATCH] phy: export phy_mii_ioctl
From: Jon Smirl @ 2007-09-19 13:56 UTC (permalink / raw)
To: Pedro Luis D. L.; +Cc: Domen Puncer, netdev, linuxppc-embedded
In-Reply-To: <BLU106-W49D16A32DDFE2611E15371CAB90@phx.gbl>
On 9/19/07, Pedro Luis D. L. <carcadiz@hotmail.com> wrote:
>
> Hello Jon,
> I´m also working with a Phytec pcm030, but I can´t get it booted...
> Which kernel are you using?
> I tried to apply the 7 bestcomm patches from Sylvain and patch over these with this new ones that Domen released.
> The base kernel I´m using is 2.6.22.6 from kernel.org.
> Although I used the patch that creates pcm030.c in arch/platforms/52xx/ and compiled using this file, it gets halted at booting time.
>
> Bytes transferred = 5091 (13e3 hex)
> ## Booting image at 00500000 ...
> Image Name: Linux-2.6.22.6
> Created: 2007-09-19 8:53:02 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1196911 Bytes = 1.1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using flat device tree at 0x400000
>
> (No more output and boot is halted)
The root name of your device tree needs to match the name in pcm030.c
pcm030_probe(void). If they don't match this happens.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [NET-2.6.24][VETH][patch 0/1] fix kernel Oops for veth
From: dlezcano @ 2007-09-19 13:38 UTC (permalink / raw)
To: davem; +Cc: xemul, netdev
When I tryed the veth driver, I fall into a kernel oops.
qemu login: Oops: 0000 [#1]
Modules linked in:
CPU: 0
EIP: 0060:[<c0265c9e>] Not tainted VLI
EFLAGS: 00000202 (2.6.23-rc6-g754f885d-dirty #33)
EIP is at __linkwatch_run_queue+0x6a/0x175
eax: c7fc9550 ebx: 6b6b6b6b ecx: c3360c80 edx: 00000246
esi: 00000001 edi: 6b6b6b6b ebp: c7fd9f7c esp: c7fd9f5c
ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068
Process events/0 (pid: 5, ti=c7fd8000 task=c7fc9550 task.ti=c7fd8000)
Stack: c7fee5a8 c0387680 c7fd9f74 c02e1aaa 4f732564 c0387684 c7fee5a8 c0387680
c7fd9f84 c0265dc9 c7fd9fac c011fb3c c7fd9f94 c02e277e c7fd9fac c02e1166
c0265da9 c7fee5a8 c0120203 c7fd9fc8 c7fd9fd0 c01202ba 00000000 c7fc9550
Call Trace:
[<c0102c69>] show_trace_log_lvl+0x1a/0x2f
[<c0102d1b>] show_stack_log_lvl+0x9d/0xa5
[<c0102ee1>] show_registers+0x1be/0x28f
[<c010309a>] die+0xe8/0x208
[<c010d5a1>] do_page_fault+0x4ba/0x595
[<c02e2842>] error_code+0x6a/0x70
[<c0265dc9>] linkwatch_event+0x20/0x27
[<c011fb3c>] run_workqueue+0x7c/0x102
[<c01202ba>] worker_thread+0xb7/0xc5
[<c012270c>] kthread+0x39/0x61
[<c0102913>] kernel_thread_helper+0x7/0x10
=======================
Code: b8 60 76 38 c0 e8 e3 ca 07 00 b8 60 76 38 c0 8b 1d 78 a7 3d c0 c7 05 78 a7 3d c0 00 00 00 00 e8 df ca 07 00 e9 ed 00 00 00 85 f6 <8b> bb f4 01 00 00 74 17 89 d8 e8 73 fe ff ff 85 c0 75 0c 89 d8
EIP: [<c0265c9e>] __linkwatch_run_queue+0x6a/0x175 SS:ESP 0068:c7fd9f5c
Slab corruption: size-2048 start=c473eac8, len=2048
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c025be72>](free_netdev+0x1f/0x41)
200: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b c0 e2 73 c4
Prev obj: start=c473e2b0, len=2048
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c025bed0>](alloc_netdev_mq+0x3c/0xa1)
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
010: 76 65 74 68 30 00 00 00 00 00 00 00 00 00 00 00
Next obj: start=c473f2e0, len=2048
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0260e69>](neigh_sysctl_unregister+0x2b/0x2e)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
That happens when trying to add the veth driver using the ip command:
ip link add veth0
which fail.
It appears that the netif_carrier_off is placed into the setup function
and this one is called before register_netdevice.
The register_netdevice function does a lot of initialization to the netdev
and if the netif_carrier_off is called before the register_netdev function,
it will use and trigger an event for an uninitialized netdev.
--
^ permalink raw reply
* [NET-2.6.24][VETH][patch 1/1] fix bad netif_carrier_off place
From: dlezcano @ 2007-09-19 13:38 UTC (permalink / raw)
To: davem; +Cc: xemul, netdev
In-Reply-To: <20070919133821.495385952@mai.toulouse-stg.fr.ibm.com>
[-- Attachment #1: fix-veth-netcarrier-off.patch --]
[-- Type: text/plain, Size: 1145 bytes --]
From: Daniel Lezcano <dlezcano@fr.ibm.com>
If the netif_carrier_off is called before register_netdev
that will use and generate an event for a non initialized network
device and that leads to a Oops.
I moved the netif_carrier_off from the setup function after each
register_netdev call.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
---
drivers/net/veth.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: net-2.6.24/drivers/net/veth.c
===================================================================
--- net-2.6.24.orig/drivers/net/veth.c
+++ net-2.6.24/drivers/net/veth.c
@@ -286,7 +286,6 @@ static void veth_setup(struct net_device
dev->features |= NETIF_F_LLTX;
dev->init = veth_dev_init;
dev->destructor = veth_dev_free;
- netif_carrier_off(dev);
}
/*
@@ -357,6 +356,8 @@ static int veth_newlink(struct net_devic
if (err < 0)
goto err_register_peer;
+ netif_carrier_off(peer);
+
/*
* register dev last
*
@@ -382,6 +383,8 @@ static int veth_newlink(struct net_devic
if (err < 0)
goto err_register_dev;
+ netif_carrier_off(dev);
+
/*
* tie the deviced together
*/
--
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox