* RE: Problems with Broadcom and Intel PRO/1000 cards
From: Alejandro Bonilla @ 2005-06-02 13:04 UTC (permalink / raw)
To: 'Alfredo Beaumont Sainz', netdev
In-Reply-To: <200506021238.25615.jtbbesaa@aintel.bi.ehu.es>
> Hi,
>
> I've a dual opteron machine with an integrated dual Broadcom
> 5704 10/100/1000
> (tg3 driver) and an Intel PRO/1000 MT (e1000 driver). It
> seems that I cannot
> make them work a Gbps. I've a crossover cable connecting a
> interface of the
> Broadcom (eth1) with the Intel (eth2), but they connect at 100Mbps:
>
Only time that I have seen this before, it was because I was using an
incorrect cable. Make sure you have the _REAL_ Gb crossover cable.
http://logout.sh/computers/net/gigabit/
Also, I would trust in dmesg and not in some other tool.
.Alejandro
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: jamal @ 2005-06-02 12:26 UTC (permalink / raw)
To: Jon Mason
Cc: David S. Miller, mitch.a.williams, shemminger, netdev,
Robert.Olsson, john.ronciak, ganesh.venkatesan, jesse.brandeburg
In-Reply-To: <200505311828.44304.jdmason@us.ibm.com>
On Tue, 2005-31-05 at 18:28 -0500, Jon Mason wrote:
> On Tuesday 31 May 2005 05:14 pm, David S. Miller wrote:
> > From: Jon Mason <jdmason@us.ibm.com>
> > Date: Tue, 31 May 2005 17:07:54 -0500
> >
> > > Of course some performace analysis would have to be done to determine the
> > > optimal numbers for each speed/duplexity setting per driver.
> >
> > per cpu speed, per memory bus speed, per I/O bus speed, and add in other
> > complications such as NUMA
> >
> > My point is that whatever experimental number you come up with will be
> > good for that driver on your systems, not necessarily for others.
> >
> > Even within a system, whatever number you select will be the wrong
> > thing to use if one starts a continuous I/O stream to the SATA
> > controller in the next PCI slot, for example.
> >
> > We keep getting bitten by this, as the Altix perf data continually shows,
> > and we need to absolutely stop thinking this way.
> >
> > The way to go is to make selections based upon observed events and
> > mesaurements.
>
> I'm not arguing against a /proc entry to tune dev->weight for those sysadmins
> advanced enough to do that. I am arguing that we can make the driver smarter
> (at little/no cost) for "out of the box" users.
>
What is the point of making the driver "smarter"?
Recall, the algorithm used to schedule the netdevices is based on an
extension of Weighted Round Robin from Varghese et al known as DRR (ask
gooogle for details).
The idea is to provide fairness amongst many drivers. As an example, if
you have a gige driver it shouldnt be taking all the resources at the
expense of starving the fastether driver.
If the admin wants one driver to be more "important" than the other,
s/he will make sure it has a higher weight.
cheers,
jamal
^ permalink raw reply
* 2.6.12-rc5-mm2: "bic unavailable using TCP reno" messages
From: Adrian Bunk @ 2005-06-02 12:15 UTC (permalink / raw)
To: Andrew Morton, shemminger; +Cc: linux-kernel, netdev
In-Reply-To: <20050601022824.33c8206e.akpm@osdl.org>
On Wed, Jun 01, 2005 at 02:28:24AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.12-rc5-mm1:
>...
> +tcp-tcp_infra.patch
>...
> Steve Hemminger's TCP enhancements.
>...
I said "no" to CONFIG_TCP_CONG_BIC, and now my syslog is full of messages
kernel: bic unavailable using TCP reno
I have no problem with such a message being shown once - but once should
be enough.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Problems with Broadcom and Intel PRO/1000 cards
From: Anders K. Pedersen @ 2005-06-02 11:34 UTC (permalink / raw)
To: netdev
In-Reply-To: <200506021238.25615.jtbbesaa@aintel.bi.ehu.es>
Alfredo Beaumont Sainz wrote:
> I've a dual opteron machine with an integrated dual Broadcom 5704 10/100/1000
> (tg3 driver) and an Intel PRO/1000 MT (e1000 driver). It seems that I cannot
> make them work a Gbps. I've a crossover cable connecting a interface of the
> Broadcom (eth1) with the Intel (eth2), but they connect at 100Mbps:
>
> # /sbin/mii-tool -v
mii-tool does not (yet) support more than 100 Mbit/s, so it will report
a 1000 Mbit/s connection as only running 100 Mbit/s. Use ethtool for now.
Regards,
Anders K. Pedersen
^ permalink raw reply
* Problems with Broadcom and Intel PRO/1000 cards
From: Alfredo Beaumont Sainz @ 2005-06-02 10:38 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]
Hi,
I've a dual opteron machine with an integrated dual Broadcom 5704 10/100/1000
(tg3 driver) and an Intel PRO/1000 MT (e1000 driver). It seems that I cannot
make them work a Gbps. I've a crossover cable connecting a interface of the
Broadcom (eth1) with the Intel (eth2), but they connect at 100Mbps:
# /sbin/mii-tool -v
eth1: negotiated 100baseTx-FD, link ok
product info: vendor 00:08:18, model 25 rev 0
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
eth2: negotiated 100baseTx-FD, link ok
product info: vendor 00:50:43, model 2 rev 5
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
As you can see, there's no 1000 FD advsertising. Forcing it with ethtool makes
them lose link connection:
# /usr/sbin/ethtool -s eth1 speed 1000 duplex full
# /sbin/mii-tool -v
eth1: no link
product info: vendor 00:08:18, model 25 rev 0
basic mode: autonegotiation enabled
basic status: no link
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
eth2: no link
product info: vendor 00:50:43, model 2 rev 5
basic mode: autonegotiation enabled
basic status: no link
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
After some secs link is recovered, at 100 again, and dmesg shows the following
kernel messages:
tg3: eth1: Link is down.
e1000: eth2: e1000_watchdog: NIC Link is Down
tg3: eth1: Link is up at 1000 Mbps, full duplex.
tg3: eth1: Flow control is off for TX and off for RX.
e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
According to the messages links would be at 1000 but they are not really. The
same happens when forcing eth2.
I'm using kernel version 2.6.11.11 but it also happened with previous version
of the kernel.
Any hints? Thanks.
--
Alfredo Beaumont. GPG: http://aintel.bi.ehu.es/~jtbbesaa/jtbbesaa.gpg.asc
Elektronika eta Telekomunikazioak Saila (Ingeniaritza Telematikoa)
Euskal Herriko Unibertsitatea, Bilbao (Basque Country). http://www.ehu.es
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [SCTP] Replace spin_lock_irqsave with spin_lock_bh
From: Herbert Xu @ 2005-06-02 9:54 UTC (permalink / raw)
To: David S. Miller, netdev
In-Reply-To: <20050602094404.GA10316@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 772 bytes --]
Hi Dave:
This patch replaces the spin_lock_irqsave call on the receive queue
lock in SCTP with spin_lock_bh. Despite the proliferation of
spin_lock_irqsave calls in this stack, it is only entered from the
IPv4/IPv6 stack and user space. That is, it is never entered from
hardirq context.
The call in question is only called from recvmsg which means that
IRQs aren't disabled. Therefore it is safe to replace it with
spin_lock_bh.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
As before, this should probably only go into net-2.6.13.
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
[-- Attachment #2: p --]
[-- Type: text/plain, Size: 693 bytes --]
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4368,15 +4368,11 @@ static struct sk_buff *sctp_skb_recv_dat
* However, this function was corrent in any case. 8)
*/
if (flags & MSG_PEEK) {
- unsigned long cpu_flags;
-
- sctp_spin_lock_irqsave(&sk->sk_receive_queue.lock,
- cpu_flags);
+ spin_lock_bh(&sk->sk_receive_queue.lock);
skb = skb_peek(&sk->sk_receive_queue);
if (skb)
atomic_inc(&skb->users);
- sctp_spin_unlock_irqrestore(&sk->sk_receive_queue.lock,
- cpu_flags);
+ spin_unlock_bh(&sk->sk_receive_queue.lock);
} else {
skb = skb_dequeue(&sk->sk_receive_queue);
}
^ permalink raw reply
* [IPV4/IPV6] Replace spin_lock_irq with spin_lock_bh
From: Herbert Xu @ 2005-06-02 9:44 UTC (permalink / raw)
To: David S. Miller, netdev
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
Hi Dave:
In light of my recent patch to net/ipv4/udp.c that replaced the
spin_lock_irq calls on the receive queue lock with spin_lock_bh,
here is a similar patch for all other occurences of spin_lock_irq
on receive/error queue locks in IPv4 and IPv6.
In these stacks, we know that they can only be entered from user
or softirq context. Therefore it's safe to disable BH only.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Since this patch simply improves the consistent use of locking
primitives rather fixing any real bugs, it should probably go
into net-2.6.13.
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
[-- Attachment #2: p --]
[-- Type: text/plain, Size: 3423 bytes --]
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -360,14 +360,14 @@ int ip_recv_error(struct sock *sk, struc
err = copied;
/* Reset and regenerate socket error */
- spin_lock_irq(&sk->sk_error_queue.lock);
+ spin_lock_bh(&sk->sk_error_queue.lock);
sk->sk_err = 0;
if ((skb2 = skb_peek(&sk->sk_error_queue)) != NULL) {
sk->sk_err = SKB_EXT_ERR(skb2)->ee.ee_errno;
- spin_unlock_irq(&sk->sk_error_queue.lock);
+ spin_unlock_bh(&sk->sk_error_queue.lock);
sk->sk_error_report(sk);
} else
- spin_unlock_irq(&sk->sk_error_queue.lock);
+ spin_unlock_bh(&sk->sk_error_queue.lock);
out_free_skb:
kfree_skb(skb);
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -691,11 +691,11 @@ static int raw_ioctl(struct sock *sk, in
struct sk_buff *skb;
int amount = 0;
- spin_lock_irq(&sk->sk_receive_queue.lock);
+ spin_lock_bh(&sk->sk_receive_queue.lock);
skb = skb_peek(&sk->sk_receive_queue);
if (skb != NULL)
amount = skb->len;
- spin_unlock_irq(&sk->sk_receive_queue.lock);
+ spin_unlock_bh(&sk->sk_receive_queue.lock);
return put_user(amount, (int __user *)arg);
}
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -353,14 +353,14 @@ int ipv6_recv_error(struct sock *sk, str
err = copied;
/* Reset and regenerate socket error */
- spin_lock_irq(&sk->sk_error_queue.lock);
+ spin_lock_bh(&sk->sk_error_queue.lock);
sk->sk_err = 0;
if ((skb2 = skb_peek(&sk->sk_error_queue)) != NULL) {
sk->sk_err = SKB_EXT_ERR(skb2)->ee.ee_errno;
- spin_unlock_irq(&sk->sk_error_queue.lock);
+ spin_unlock_bh(&sk->sk_error_queue.lock);
sk->sk_error_report(sk);
} else {
- spin_unlock_irq(&sk->sk_error_queue.lock);
+ spin_unlock_bh(&sk->sk_error_queue.lock);
}
out_free_skb:
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -434,12 +434,12 @@ csum_copy_err:
/* Clear queue. */
if (flags&MSG_PEEK) {
int clear = 0;
- spin_lock_irq(&sk->sk_receive_queue.lock);
+ spin_lock_bh(&sk->sk_receive_queue.lock);
if (skb == skb_peek(&sk->sk_receive_queue)) {
__skb_unlink(skb, &sk->sk_receive_queue);
clear = 1;
}
- spin_unlock_irq(&sk->sk_receive_queue.lock);
+ spin_unlock_bh(&sk->sk_receive_queue.lock);
if (clear)
kfree_skb(skb);
}
@@ -971,11 +971,11 @@ static int rawv6_ioctl(struct sock *sk,
struct sk_buff *skb;
int amount = 0;
- spin_lock_irq(&sk->sk_receive_queue.lock);
+ spin_lock_bh(&sk->sk_receive_queue.lock);
skb = skb_peek(&sk->sk_receive_queue);
if (skb != NULL)
amount = skb->tail - skb->h.raw;
- spin_unlock_irq(&sk->sk_receive_queue.lock);
+ spin_unlock_bh(&sk->sk_receive_queue.lock);
return put_user(amount, (int __user *)arg);
}
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -300,12 +300,12 @@ csum_copy_err:
/* Clear queue. */
if (flags&MSG_PEEK) {
int clear = 0;
- spin_lock_irq(&sk->sk_receive_queue.lock);
+ spin_lock_bh(&sk->sk_receive_queue.lock);
if (skb == skb_peek(&sk->sk_receive_queue)) {
__skb_unlink(skb, &sk->sk_receive_queue);
clear = 1;
}
- spin_unlock_irq(&sk->sk_receive_queue.lock);
+ spin_unlock_bh(&sk->sk_receive_queue.lock);
if (clear)
kfree_skb(skb);
}
^ permalink raw reply
* RE: Unable to handle kernel paging request at virtual address 04000460
From: raghunathan.venkatesan @ 2005-06-02 3:50 UTC (permalink / raw)
To: davem; +Cc: linux-net, netdev, linux
Hi David,
I understand that the linux community may not be able to debug it for
me. All I require is if people have seen similar problems (the problems
we face are w.r.t to kfree_skb and skb_drop_fraglist crashing due to
some reason, which could be a Memory Management issue or some thing we
are not aware of), then let us know the patches, so that we can try them
out here.
Thankyou for your response.
Regards,
Raghu
-----Original Message-----
From: David S. Miller [mailto:davem@davemloft.net]
Sent: Thursday, June 02, 2005 12:25 AM
To: Raghunathan Venkatesan (WT01 - EMBEDDED & PRODUCT ENGINEERING
SOLUTIONS)
Cc: linux-net@vger.kernel.org; netdev@oss.sgi.com; linux@der-keiler.de
Subject: Re: Unable to handle kernel paging request at virtual address
04000460
Please don't ask the community to debug your custom kernel with private
VPN driver modules installed.
^ permalink raw reply
* Re: [PATCH] ieee80211: Update generic definitions to latest specs.
From: Gertjan van Wingerde @ 2005-06-02 3:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, jgarzik
In-Reply-To: <20050601143734.3b7a49ca@dxpl.pdx.osdl.net>
Stephen Hemminger wrote:
>On Wed, 01 Jun 2005 22:50:51 +0200
>Gertjan van Wingerde <gwingerde@home.nl> wrote:
>
>
>
>>Hi,
>>
>>Attached patch updates the definitions of the generic ieee80211 stack to
>>the latest versions of the published 802.11x specification suite.
>>Please review and apply.
>>
>>Signed-off-by: Gertjan van Wingerde <gwingerde@home.nl>
>>
>>
>>
>Could you change the elements that fix to be enum's instead of define's
>
>example:
>
>/* Management Frame Information Element Types */
>enum ieee80211_mfie {
> MFIE_TYPE_SSID = 0,
> MFIE_TYPE_RATES = 1,
> MFIE_TYPE_FH_SET= 2,
>...
>
Hi Stephen,
Well, my patch is really just an add-on to the existing code. Converting
to enums is really a follow-up patch that can be applied on top of this one.
I'm happy to produce a patch if everybody agrees.
Jeff, any opinions on this?
Best regards,
Gertjan.
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Andy Fleming @ 2005-06-01 22:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <429E2653.6010101@osdl.org>
On Jun 1, 2005, at 16:19, Stephen Hemminger wrote:
> Andy Fleming wrote:
>>
>> But not this one. The phy_read and phy_write functions are
>> reading from and writing to a bus. It is a reasonable
>> implementation to have the operation block in the bus driver, and
>> be awoken when an interrupt signals the operation is done. All
>> of the phydev spinlocks have been arranged so as to prevent the
>> lock being taken during interrupt time.
>>
>> Unless I've misunderstood spinlocks (it wouldn't be the first
>> time), as long as the lock is never taken in interrupt time, it
>> should be ok to hold the lock, and wait for an interrupt before
>> clearing the lock.
>>
>
>
> The problem is that sleeping is defined in the linux kernel as
> meaning waiting on a mutual exclusion
> primitive (like semaphore) that puts the current thread to sleep.
> It is not legal to sleep with a spinlock held.
> In the phy_read code you do:
> spin_lock_bh(&bus->mdio_lock);
> retval = bus->read(bus, phydev->addr, regnum);
> spin_unlock_bh(&bus->mdio_lock);
>
> If the bus->read function were to do something like start a request
> and wait on a semaphore, then
> you would be sleeping with a spin lock held. So bus->read can not
> sleep! (as sleep is defined in the
> linux kernel).
Hmm... I understand this reasoning, but I still need a way for a bus
read to wait for an interrupt before returning. I suppose I can just
have the code spin while it waits, but that seems wrong, somehow.
I'm open to any suggestions.
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Andy Fleming @ 2005-06-01 22:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <20050601144123.2bc11c06@dxpl.pdx.osdl.net>
On Jun 1, 2005, at 16:41, Stephen Hemminger wrote:
> On Wed, 1 Jun 2005 15:45:26 -0500
> Andy Fleming <afleming@freescale.com> wrote:
>>
>>> * get rid of bus read may sleep implication in comment.
>>> since you are holding phy spin lock it better not!!
>>>
>>
>>
>
> On a different note, I am not sure that using sysfs/kobject bus object
> is the right thing for this object. Isn't the phy instance really
> just
> an kobject whose parent is the network device? I can't see a 1 to N
> relationship between phy bus and phy objects existing.
Well, the MII Management bus is, in fact, a bus. When a network
driver wants to modify a PHY, it must access that bus. Many ethernet
controllers have a 1 to 1 relationship, since a typical NIC is a PCI
card with 1 ethernet port (meaning one controller, and one PHY).
However, many systems have multiple ethernet controllers attached to
one bus, which configures multiple PHYs. Currently, these systems
have been relying on luck to prevent multiple accesses to the same bus.
This tends to work because all of the PHY support is contained within
the ethernet driver, so it is easy for such drivers to ensure that
only one PHY transaction is done at a time. This system begins to
fall apart, though, when the PHY drivers start operating more
independently to react to changing PHY state. It really begins to
fall apart if you have multiple drivers trying to access a shared
bus. For instance, the 8560 ADS board has 2 gigabit ethernet ports
controlled by the gianfar driver, and 2 10/100 ports in the CPM
subsystem, controlled by the fcc_enet driver.
These two drivers each have an access point for the bus, which use
different mechanisms (one is a bit bang interface, and one is
register based). Using the new abstraction, it is possible for the
FCC driver to use the gianfar driver's bus, thus saving code, and
reducing complexity.
>
> The main use I can see for being a driver object is to catch
> suspend/resume,
> and wouldn't you want that to be tied to the network device.
It would be quite easy for the network driver to suspend or resume
the PHY and bus objects under the new abstraction. However, if eth0
is suspended, should it suspend the whole bus, and all the PHYs on
it? By making the MII bus an independent entity, eth0 can be
suspended, and it can choose to suspend its PHY, but eth1 can
continue to access its PHY over the bus, since those aren't suspended.
^ permalink raw reply
* Re: Locking model for NAPI drivers
From: David S. Miller @ 2005-06-01 22:21 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1117658019.4310.58.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 01 Jun 2005 13:33:39 -0700
> I suppose we can enable interrupts in tg3_irq_quiesce() after setting
> the SYNC bit.
Since the caller shuts down NAPI ->poll(), after setting the SYNC bit
we can just check the MAILBOX register, and if a '1' is there just
return. Does one need to mask out the upper bits of the regiser in
order to avoid seeing the IRQ tag in such a comparison?
Another potential problem is if the chip is hung for some reason,
and even though an interrupt is asserted it does not send the
interrupt. We'd hang in this case as well. Therefore it may be
wise to add a timeout to the COMPLETE bit polling loop in order
to handle such cases properly.
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Stephen Hemminger @ 2005-06-01 21:41 UTC (permalink / raw)
To: Andy Fleming; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com>
On Wed, 1 Jun 2005 15:45:26 -0500
Andy Fleming <afleming@freescale.com> wrote:
>
> On May 31, 2005, at 12:59, Stephen Hemminger wrote:
>
> > Here are some patches:
> > * allow phy's to be modules
> > * use driver owner for ref count
> > * make local functions static where ever possible
>
> I agree with all these.
>
> > * get rid of bus read may sleep implication in comment.
> > since you are holding phy spin lock it better not!!
>
On a different note, I am not sure that using sysfs/kobject bus object
is the right thing for this object. Isn't the phy instance really just
an kobject whose parent is the network device? I can't see a 1 to N
relationship between phy bus and phy objects existing.
The main use I can see for being a driver object is to catch suspend/resume,
and wouldn't you want that to be tied to the network device.
^ permalink raw reply
* Re: [PATCH] ieee80211: Update generic definitions to latest specs.
From: Stephen Hemminger @ 2005-06-01 21:37 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: netdev, jgarzik
In-Reply-To: <429E1FAB.6080503@home.nl>
On Wed, 01 Jun 2005 22:50:51 +0200
Gertjan van Wingerde <gwingerde@home.nl> wrote:
> Hi,
>
> Attached patch updates the definitions of the generic ieee80211 stack to
> the latest versions of the published 802.11x specification suite.
> Please review and apply.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@home.nl>
>
Could you change the elements that fix to be enum's instead of define's
example:
/* Management Frame Information Element Types */
enum ieee80211_mfie {
MFIE_TYPE_SSID = 0,
MFIE_TYPE_RATES = 1,
MFIE_TYPE_FH_SET= 2,
...
^ permalink raw reply
* Re: Locking model for NAPI drivers
From: Michael Chan @ 2005-06-01 21:34 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050601.152134.120445266.davem@davemloft.net>
On Wed, 2005-06-01 at 15:21 -0700, David S. Miller wrote:
> From: "Michael Chan" <mchan@broadcom.com>
> Date: Wed, 01 Jun 2005 13:33:39 -0700
>
> > I suppose we can enable interrupts in tg3_irq_quiesce() after setting
> > the SYNC bit.
>
> Since the caller shuts down NAPI ->poll(), after setting the SYNC bit
> we can just check the MAILBOX register, and if a '1' is there just
> return. Does one need to mask out the upper bits of the regiser in
> order to avoid seeing the IRQ tag in such a comparison?
>
No, just check for the value 1 since that's the value we use to disable
interrupts. The value read back will always be 1 if 1 was previously
written to it.
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Stephen Hemminger @ 2005-06-01 21:19 UTC (permalink / raw)
To: Andy Fleming; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com>
Andy Fleming wrote:
>
> On May 31, 2005, at 12:59, Stephen Hemminger wrote:
>
>> Here are some patches:
>> * allow phy's to be modules
>> * use driver owner for ref count
>> * make local functions static where ever possible
>
>
> I agree with all these.
>
>> * get rid of bus read may sleep implication in comment.
>> since you are holding phy spin lock it better not!!
>
>
> But not this one. The phy_read and phy_write functions are reading
> from and writing to a bus. It is a reasonable implementation to have
> the operation block in the bus driver, and be awoken when an
> interrupt signals the operation is done. All of the phydev spinlocks
> have been arranged so as to prevent the lock being taken during
> interrupt time.
>
> Unless I've misunderstood spinlocks (it wouldn't be the first time),
> as long as the lock is never taken in interrupt time, it should be ok
> to hold the lock, and wait for an interrupt before clearing the lock.
The problem is that sleeping is defined in the linux kernel as meaning
waiting on a mutual exclusion
primitive (like semaphore) that puts the current thread to sleep. It is
not legal to sleep with a spinlock held.
In the phy_read code you do:
spin_lock_bh(&bus->mdio_lock);
retval = bus->read(bus, phydev->addr, regnum);
spin_unlock_bh(&bus->mdio_lock);
If the bus->read function were to do something like start a request and
wait on a semaphore, then
you would be sleeping with a spin lock held. So bus->read can not
sleep! (as sleep is defined in the
linux kernel).
^ permalink raw reply
* [PATCH] ieee80211: Update generic definitions to latest specs.
From: Gertjan van Wingerde @ 2005-06-01 20:50 UTC (permalink / raw)
To: netdev, jgarzik
[-- Attachment #1: Type: text/plain, Size: 228 bytes --]
Hi,
Attached patch updates the definitions of the generic ieee80211 stack to
the latest versions of the published 802.11x specification suite.
Please review and apply.
Signed-off-by: Gertjan van Wingerde <gwingerde@home.nl>
[-- Attachment #2: ieee80211.diff --]
[-- Type: text/plain, Size: 10321 bytes --]
Index: include/net/ieee80211.h
===================================================================
--- 4b4ba76aa81b3627142787262fd2f8049dd3662d/include/net/ieee80211.h (mode:100644)
+++ uncommitted/include/net/ieee80211.h (mode:100644)
@@ -103,7 +103,7 @@
#define MAX_FRAG_THRESHOLD 2346U
/* Frame control field constants */
-#define IEEE80211_FCTL_VERS 0x0002
+#define IEEE80211_FCTL_VERS 0x0003
#define IEEE80211_FCTL_FTYPE 0x000c
#define IEEE80211_FCTL_STYPE 0x00f0
#define IEEE80211_FCTL_TODS 0x0100
@@ -111,8 +111,8 @@
#define IEEE80211_FCTL_MOREFRAGS 0x0400
#define IEEE80211_FCTL_RETRY 0x0800
#define IEEE80211_FCTL_PM 0x1000
-#define IEEE80211_FCTL_MOREDATA 0x2000
-#define IEEE80211_FCTL_WEP 0x4000
+#define IEEE80211_FCTL_MOREDATA 0x2000
+#define IEEE80211_FCTL_PROTECTEDFRAME 0x4000
#define IEEE80211_FCTL_ORDER 0x8000
#define IEEE80211_FTYPE_MGMT 0x0000
@@ -131,6 +131,7 @@
#define IEEE80211_STYPE_DISASSOC 0x00A0
#define IEEE80211_STYPE_AUTH 0x00B0
#define IEEE80211_STYPE_DEAUTH 0x00C0
+#define IEEE80211_STYPE_ACTION 0x00D0
/* control */
#define IEEE80211_STYPE_PSPOLL 0x00A0
@@ -251,6 +252,7 @@
#define SNAP_SIZE sizeof(struct ieee80211_snap_hdr)
+#define WLAN_FC_GET_VERS(fc) ((fc) & IEEE80211_FCTL_VERS)
#define WLAN_FC_GET_TYPE(fc) ((fc) & IEEE80211_FCTL_FTYPE)
#define WLAN_FC_GET_STYPE(fc) ((fc) & IEEE80211_FCTL_STYPE)
@@ -271,6 +273,9 @@
#define WLAN_CAPABILITY_SHORT_PREAMBLE (1<<5)
#define WLAN_CAPABILITY_PBCC (1<<6)
#define WLAN_CAPABILITY_CHANNEL_AGILITY (1<<7)
+#define WLAN_CAPABILITY_SPECTRUM_MGMT (1<<8)
+#define WLAN_CAPABILITY_SHORT_SLOT_TIME (1<<10)
+#define WLAN_CAPABILITY_OSSS_OFDM (1<<13)
/* Status codes */
#define WLAN_STATUS_SUCCESS 0
@@ -285,9 +290,24 @@
#define WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA 17
#define WLAN_STATUS_ASSOC_DENIED_RATES 18
/* 802.11b */
-#define WLAN_STATUS_ASSOC_DENIED_NOSHORT 19
+#define WLAN_STATUS_ASSOC_DENIED_NOSHORTPREAMBLE 19
#define WLAN_STATUS_ASSOC_DENIED_NOPBCC 20
#define WLAN_STATUS_ASSOC_DENIED_NOAGILITY 21
+/* 802.11h */
+#define WLAN_STATUS_ASSOC_DENIED_SPECTRUM_MGMT_REQUIRED 22
+#define WLAN_STATUS_ASSOC_REJECTED_POWER_CAP_UNACCEPTABLE 23
+#define WLAN_STATUS_ASSOC_REJECTED_SUPP_CHANNELS_UNACCEPTABLE 24
+/* 802.11g */
+#define WLAN_STATUS_ASSOC_DENIED_NOSHORTTIME 25
+#define WLAN_STATUS_ASSOC_DENIED_NODSSSOFDM 26
+/* 802.11i */
+#define WLAN_STATUS_INVALID_IE 40
+#define WLAN_STATUS_INVALID_GROUP_CIPHER 41
+#define WLAN_STATUS_INVALID_PAIRWISE_CIPHER 42
+#define WLAN_STATUS_INVALID_AKMP 43
+#define WLAN_STATUS_UNSUPP_RSN_VERSION 44
+#define WLAN_STATUS_INVALID_RSN_IE_CAP 45
+#define WLAN_STATUS_CIPHER_SUITE_REJECTED 46
/* Reason codes */
#define WLAN_REASON_UNSPECIFIED 1
@@ -299,6 +319,22 @@
#define WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA 7
#define WLAN_REASON_DISASSOC_STA_HAS_LEFT 8
#define WLAN_REASON_STA_REQ_ASSOC_WITHOUT_AUTH 9
+/* 802.11h */
+#define WLAN_REASON_DISASSOC_POWER_CAP_UNACCEPTABLE 10
+#define WLAN_REASON_DISASSOC_SUPP_CHANNELS_UNACCEPTABLE 11
+/* 802.11i */
+#define WLAN_REASON_INVALID_IE 13
+#define WLAN_REASON_MIC_FAILURE 14
+#define WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT 15
+#define WLAN_REASON_GROUP_KEY_HANDSHAKE_TIMEOUT 16
+#define WLAN_REASON_IE_DIFFERENT 17
+#define WLAN_REASON_INVALID_GROUP_CIPHER 18
+#define WLAN_REASON_INVALID_PAIRWISE_CIPHER 19
+#define WLAN_REASON_INVALID_AKMP 20
+#define WLAN_REASON_UNSUPP_RSN_VERSION 21
+#define WLAN_REASON_INVALID_RSN_IE_CAP 22
+#define WLAN_REASON_IEEE8021X_FAILED 23
+#define WLAN_REASON_CIPHER_SUITE_REJECTED 24
#define IEEE80211_STATMASK_SIGNAL (1<<0)
@@ -477,17 +513,32 @@
#define BEACON_PROBE_SSID_ID_POSITION 12
/* Management Frame Information Element Types */
-#define MFIE_TYPE_SSID 0
-#define MFIE_TYPE_RATES 1
-#define MFIE_TYPE_FH_SET 2
-#define MFIE_TYPE_DS_SET 3
-#define MFIE_TYPE_CF_SET 4
-#define MFIE_TYPE_TIM 5
-#define MFIE_TYPE_IBSS_SET 6
-#define MFIE_TYPE_CHALLENGE 16
-#define MFIE_TYPE_RSN 48
-#define MFIE_TYPE_RATES_EX 50
-#define MFIE_TYPE_GENERIC 221
+#define MFIE_TYPE_SSID 0
+#define MFIE_TYPE_RATES 1
+#define MFIE_TYPE_FH_SET 2
+#define MFIE_TYPE_DS_SET 3
+#define MFIE_TYPE_CF_SET 4
+#define MFIE_TYPE_TIM 5
+#define MFIE_TYPE_IBSS_SET 6
+#define MFIE_TYPE_COUNTRY 7
+#define MFIE_TYPE_HOP_PARAMS 8
+#define MFIE_TYPE_HOP_TABLE 9
+#define MFIE_TYPE_REQUEST 10
+#define MFIE_TYPE_CHALLENGE 16
+#define MFIE_TYPE_POWER_CONSTRAINT 32
+#define MFIE_TYPE_POWER_CAPABILITY 33
+#define MFIE_TYPE_TPC_REQUEST 34
+#define MFIE_TYPE_TPC_REPORT 35
+#define MFIE_TYPE_SUPP_CHANNELS 36
+#define MFIE_TYPE_CSA 37
+#define MFIE_TYPE_MEASURE_REQUEST 38
+#define MFIE_TYPE_MEASURE_REPORT 39
+#define MFIE_TYPE_QUIET 40
+#define MFIE_TYPE_IBSS_DFS 41
+#define MFIE_TYPE_ERP_INFO 42
+#define MFIE_TYPE_RSN 48
+#define MFIE_TYPE_RATES_EX 50
+#define MFIE_TYPE_GENERIC 221
struct ieee80211_info_element_hdr {
u8 id;
Index: net/ieee80211/ieee80211_rx.c
===================================================================
--- 4b4ba76aa81b3627142787262fd2f8049dd3662d/net/ieee80211/ieee80211_rx.c (mode:100644)
+++ uncommitted/net/ieee80211/ieee80211_rx.c (mode:100644)
@@ -440,7 +440,7 @@
crypt->ops->decrypt_mpdu == NULL))
crypt = NULL;
- if (!crypt && (fc & IEEE80211_FCTL_WEP)) {
+ if (!crypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME)) {
/* This seems to be triggered by some (multicast?)
* frames from other than current BSS, so just drop the
* frames silently instead of filling system log with
@@ -456,7 +456,7 @@
#ifdef NOT_YET
if (type != WLAN_FC_TYPE_DATA) {
if (type == WLAN_FC_TYPE_MGMT && stype == WLAN_FC_STYPE_AUTH &&
- fc & IEEE80211_FCTL_WEP && ieee->host_decrypt &&
+ fc & IEEE80211_FCTL_PROTECTEDFRAME && ieee->host_decrypt &&
(keyidx = hostap_rx_frame_decrypt(ieee, skb, crypt)) < 0)
{
printk(KERN_DEBUG "%s: failed to decrypt mgmt::auth "
@@ -557,7 +557,7 @@
/* skb: hdr + (possibly fragmented, possibly encrypted) payload */
- if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) &&
+ if (ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME) &&
(keyidx = ieee80211_rx_frame_decrypt(ieee, skb, crypt)) < 0)
goto rx_dropped;
@@ -565,7 +565,7 @@
/* skb: hdr + (possibly fragmented) plaintext payload */
// PR: FIXME: hostap has additional conditions in the "if" below:
- // ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) &&
+ // ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME) &&
if ((frag != 0 || (fc & IEEE80211_FCTL_MOREFRAGS))) {
int flen;
struct sk_buff *frag_skb = ieee80211_frag_cache_get(ieee, hdr);
@@ -621,12 +621,12 @@
/* skb: hdr + (possible reassembled) full MSDU payload; possibly still
* encrypted/authenticated */
- if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) &&
+ if (ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME) &&
ieee80211_rx_frame_decrypt_msdu(ieee, skb, keyidx, crypt))
goto rx_dropped;
hdr = (struct ieee80211_hdr *) skb->data;
- if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep) {
+ if (crypt && !(fc & IEEE80211_FCTL_PROTECTEDFRAME) && !ieee->open_wep) {
if (/*ieee->ieee802_1x &&*/
ieee80211_is_eapol_frame(ieee, skb)) {
#ifdef CONFIG_IEEE80211_DEBUG
@@ -647,7 +647,7 @@
}
#ifdef CONFIG_IEEE80211_DEBUG
- if (crypt && !(fc & IEEE80211_FCTL_WEP) &&
+ if (crypt && !(fc & IEEE80211_FCTL_PROTECTEDFRAME) &&
ieee80211_is_eapol_frame(ieee, skb)) {
struct eapol *eap = (struct eapol *)(skb->data +
24);
@@ -656,7 +656,7 @@
}
#endif
- if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep &&
+ if (crypt && !(fc & IEEE80211_FCTL_PROTECTEDFRAME) && !ieee->open_wep &&
!ieee80211_is_eapol_frame(ieee, skb)) {
IEEE80211_DEBUG_DROP(
"dropped unencrypted RX data "
Index: net/ieee80211/ieee80211_tx.c
===================================================================
--- 4b4ba76aa81b3627142787262fd2f8049dd3662d/net/ieee80211/ieee80211_tx.c (mode:100644)
+++ uncommitted/net/ieee80211/ieee80211_tx.c (mode:100644)
@@ -314,7 +314,7 @@
if (encrypt)
fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA |
- IEEE80211_FCTL_WEP;
+ IEEE80211_FCTL_PROTECTEDFRAME;
else
fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA;
Index: drivers/net/wireless/atmel.c
===================================================================
--- 4b4ba76aa81b3627142787262fd2f8049dd3662d/drivers/net/wireless/atmel.c (mode:100644)
+++ uncommitted/drivers/net/wireless/atmel.c (mode:100644)
@@ -867,7 +867,7 @@
header.duration_id = 0;
header.seq_ctl = 0;
if (priv->wep_is_on)
- frame_ctl |= IEEE80211_FCTL_WEP;
+ frame_ctl |= IEEE80211_FCTL_PROTECTEDFRAME;
if (priv->operating_mode == IW_MODE_ADHOC) {
memcpy(&header.addr1, skb->data, 6);
memcpy(&header.addr2, dev->dev_addr, 6);
@@ -1117,7 +1117,7 @@
/* probe for CRC use here if needed once five packets have arrived with
the same crc status, we assume we know what's happening and stop probing */
if (priv->probe_crc) {
- if (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_WEP)) {
+ if (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_PROTECTEDFRAME)) {
priv->do_rx_crc = probe_crc(priv, rx_packet_loc, msdu_size);
} else {
priv->do_rx_crc = probe_crc(priv, rx_packet_loc + 24, msdu_size - 24);
@@ -1132,7 +1132,7 @@
}
/* don't CRC header when WEP in use */
- if (priv->do_rx_crc && (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_WEP))) {
+ if (priv->do_rx_crc && (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_PROTECTEDFRAME))) {
crc = crc32_le(0xffffffff, (unsigned char *)&header, 24);
}
msdu_size -= 24; /* header */
@@ -2677,7 +2677,7 @@
auth.alg = cpu_to_le16(C80211_MGMT_AAN_SHAREDKEY);
/* no WEP for authentication frames with TrSeqNo 1 */
if (priv->CurrentAuthentTransactionSeqNum != 1)
- header.frame_ctl |= cpu_to_le16(IEEE80211_FCTL_WEP);
+ header.frame_ctl |= cpu_to_le16(IEEE80211_FCTL_PROTECTEDFRAME);
} else {
auth.alg = cpu_to_le16(C80211_MGMT_AAN_OPENSYSTEM);
}
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Andy Fleming @ 2005-06-01 20:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <20050531105939.7486e071@dxpl.pdx.osdl.net>
On May 31, 2005, at 12:59, Stephen Hemminger wrote:
> Here are some patches:
> * allow phy's to be modules
> * use driver owner for ref count
> * make local functions static where ever possible
I agree with all these.
> * get rid of bus read may sleep implication in comment.
> since you are holding phy spin lock it better not!!
But not this one. The phy_read and phy_write functions are reading
from and writing to a bus. It is a reasonable implementation to have
the operation block in the bus driver, and be awoken when an
interrupt signals the operation is done. All of the phydev spinlocks
have been arranged so as to prevent the lock being taken during
interrupt time.
Unless I've misunderstood spinlocks (it wouldn't be the first time),
as long as the lock is never taken in interrupt time, it should be ok
to hold the lock, and wait for an interrupt before clearing the lock.
Andy Fleming
^ permalink raw reply
* Re: Locking model for NAPI drivers
From: Michael Chan @ 2005-06-01 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050531.154847.63995530.davem@davemloft.net>
On Tue, 2005-05-31 at 15:48 -0700, David S. Miller wrote:
> Once we make this transformation, we need some way to synchronize
> with the IRQ handler when shutting down the device or making major
> configuration changes to the chip.
>
> The idea I came up with is a two-bit atomic bitmask. When base
> level code wants to quiesce interrupt processing, it takes the
> necessary driver spinlocks, sets the "SYNC" bit in the bitmask,
> forces and IRQ to be asserted by the tg3 card, then waits for the
> COMPLETE bit to get set by the interrupt handler.
>
During light testing, I found a race condition that caused
tg3_irq_quiesce() to spin forever. The race condition is shown below.
CPU1 CPU2
tg3_interrupt_tagged()
tg3_netif_stop()
netif_poll_disable()
netif_rx_schedule() will do nothing
tg3_full_lock()
tg3_irq_quiesce()
Because netif_poll_disable() is called, netif_rx_schedule() will do
nothing in the interrupt handler. As a result, tg3_poll() will never be
called to re-enable interrupts. Since interrupts are disabled,
tg3_irq_quiesce() will not be able to set the interrupts and cause the
interrupt handler to be called again, and therefore will wait forever.
Even adding another call to tg3_irq_sync() at the end of the interrupt
handler does not eliminate the race condition.
I suppose we can enable interrupts in tg3_irq_quiesce() after setting
the SYNC bit.
^ permalink raw reply
* Re: Unable to handle kernel paging request at virtual address 04000460
From: David S. Miller @ 2005-06-01 18:54 UTC (permalink / raw)
To: raghunathan.venkatesan; +Cc: linux-net, netdev, linux
In-Reply-To: <438662DA48DCAA41B1DF648BD4BD76C0E45DF1@CHN-SNR-MBX01.wipro.com>
Please don't ask the community to debug your custom kernel with
private VPN driver modules installed.
^ permalink raw reply
* [PATCH][3/3] RapidIO support: net driver over messaging
From: Matt Porter @ 2005-06-01 18:25 UTC (permalink / raw)
To: torvalds, akpm, jgarzik; +Cc: netdev, linux-kernel, linuxppc-embedded
In-Reply-To: <20050601111516.B16559@cox.net>
Adds an "Ethernet" driver which sends Ethernet packets over the
standard RapidIO messaging. This depends on the core RIO
patch for mailbox/doorbell access.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
Index: drivers/net/Kconfig
===================================================================
--- f0bf7810dbe8c4073832d6c3785364084e9523a7/drivers/net/Kconfig (mode:100644)
+++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/Kconfig (mode:100644)
@@ -2185,6 +2185,20 @@
tristate "iSeries Virtual Ethernet driver support"
depends on NETDEVICES && PPC_ISERIES
+config RIONET
+ tristate "RapidIO Ethernet over messaging driver support"
+ depends on NETDEVICES && RAPIDIO
+
+config RIONET_TX_SIZE
+ int "Number of outbound queue entries"
+ depends on RIONET
+ default "128"
+
+config RIONET_RX_SIZE
+ int "Number of inbound queue entries"
+ depends on RIONET
+ default "128"
+
config FDDI
bool "FDDI driver support"
depends on NETDEVICES && (PCI || EISA)
Index: drivers/net/Makefile
===================================================================
--- f0bf7810dbe8c4073832d6c3785364084e9523a7/drivers/net/Makefile (mode:100644)
+++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/Makefile (mode:100644)
@@ -58,6 +58,7 @@
obj-$(CONFIG_VIA_RHINE) += via-rhine.o
obj-$(CONFIG_VIA_VELOCITY) += via-velocity.o
obj-$(CONFIG_ADAPTEC_STARFIRE) += starfire.o
+obj-$(CONFIG_RIONET) += rionet.o
#
# end link order section
Index: drivers/net/rionet.c
===================================================================
--- /dev/null (tree:f0bf7810dbe8c4073832d6c3785364084e9523a7)
+++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/rionet.c (mode:100644)
@@ -0,0 +1,622 @@
+/*
+ * rionet - Ethernet driver over RapidIO messaging services
+ *
+ * Copyright 2005 MontaVista Software, Inc.
+ * Matt Porter <mporter@kernel.crashing.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/dma-mapping.h>
+#include <linux/delay.h>
+#include <linux/rio.h>
+#include <linux/rio_drv.h>
+#include <linux/rio_ids.h>
+
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/skbuff.h>
+#include <linux/crc32.h>
+#include <linux/ethtool.h>
+
+#define DRV_NAME "rionet"
+#define DRV_VERSION "0.1"
+#define DRV_AUTHOR "Matt Porter <mporter@kernel.crashing.org>"
+#define DRV_DESC "Ethernet over RapidIO"
+
+MODULE_AUTHOR(DRV_AUTHOR);
+MODULE_DESCRIPTION(DRV_DESC);
+MODULE_LICENSE("GPL");
+
+#define RIONET_DEFAULT_MSGLEVEL 0
+#define RIONET_DOORBELL_JOIN 0x1000
+#define RIONET_DOORBELL_LEAVE 0x1001
+
+#define RIONET_MAILBOX 0
+
+#define RIONET_TX_RING_SIZE CONFIG_RIONET_TX_SIZE
+#define RIONET_RX_RING_SIZE CONFIG_RIONET_RX_SIZE
+
+LIST_HEAD(rionet_peers);
+
+struct rionet_private {
+ struct rio_mport *mport;
+ struct sk_buff *rx_skb[RIONET_RX_RING_SIZE];
+ struct sk_buff *tx_skb[RIONET_TX_RING_SIZE];
+ struct net_device_stats stats;
+ int rx_slot;
+ int tx_slot;
+ int tx_cnt;
+ int ack_slot;
+ spinlock_t lock;
+ u32 msg_enable;
+};
+
+struct rionet_peer {
+ struct list_head node;
+ struct rio_dev *rdev;
+ struct resource *res;
+};
+
+static int rionet_check = 0;
+static int rionet_capable = 1;
+static struct net_device *sndev = NULL;
+
+/*
+ * This is a fast lookup table for for translating TX
+ * Ethernet packets into a destination RIO device. It
+ * could be made into a hash table to save memory depending
+ * on system trade-offs.
+ */
+static struct rio_dev *rionet_active[RIO_MAX_ROUTE_ENTRIES];
+
+#define is_rionet_capable(pef, src_ops, dst_ops) \
+ ((pef & RIO_PEF_INB_MBOX) && \
+ (pef & RIO_PEF_INB_DOORBELL) && \
+ (src_ops & RIO_SRC_OPS_DOORBELL) && \
+ (dst_ops & RIO_DST_OPS_DOORBELL))
+#define dev_rionet_capable(dev) \
+ is_rionet_capable(dev->pef, dev->src_ops, dev->dst_ops)
+
+#define RIONET_MAC_MATCH(x) (*(u32 *)x == 0x00010001)
+#define RIONET_GET_DESTID(x) (*(u16 *)(x + 4))
+
+static struct net_device_stats *rionet_stats(struct net_device *ndev)
+{
+ struct rionet_private *rnet = ndev->priv;
+ return &rnet->stats;
+}
+
+static int rionet_rx_clean(struct net_device *ndev)
+{
+ int i;
+ int error = 0;
+ struct rionet_private *rnet = ndev->priv;
+ void *data;
+
+ i = rnet->rx_slot;
+
+ do {
+ if (!rnet->rx_skb[i]) {
+ rnet->stats.rx_dropped++;
+ continue;
+ }
+
+ if (!(data = rio_get_inb_message(rnet->mport, RIONET_MAILBOX)))
+ break;
+
+ rnet->rx_skb[i]->data = data;
+ skb_put(rnet->rx_skb[i], RIO_MAX_MSG_SIZE);
+ rnet->rx_skb[i]->dev = sndev;
+ rnet->rx_skb[i]->protocol =
+ eth_type_trans(rnet->rx_skb[i], sndev);
+ error = netif_rx(rnet->rx_skb[i]);
+
+ if (error == NET_RX_DROP) {
+ rnet->stats.rx_dropped++;
+ } else if (error == NET_RX_BAD) {
+ if (netif_msg_rx_err(rnet))
+ printk(KERN_WARNING "%s: bad rx packet\n",
+ DRV_NAME);
+ rnet->stats.rx_errors++;
+ } else {
+ rnet->stats.rx_packets++;
+ rnet->stats.rx_bytes += RIO_MAX_MSG_SIZE;
+ }
+
+ } while ((i = (i + 1) % RIONET_RX_RING_SIZE) != rnet->rx_slot);
+
+ return i;
+}
+
+static void rionet_rx_fill(struct net_device *ndev, int end)
+{
+ int i;
+ struct rionet_private *rnet = ndev->priv;
+
+ i = rnet->rx_slot;
+ do {
+ rnet->rx_skb[i] = dev_alloc_skb(RIO_MAX_MSG_SIZE);
+
+ if (!rnet->rx_skb[i])
+ break;
+
+ rio_add_inb_buffer(rnet->mport, RIONET_MAILBOX,
+ rnet->rx_skb[i]->data);
+ } while ((i = (i + 1) % RIONET_RX_RING_SIZE) != end);
+
+ rnet->rx_slot = i;
+}
+
+static int rionet_queue_tx_msg(struct sk_buff *skb, struct net_device *ndev,
+ struct rio_dev *rdev)
+{
+ struct rionet_private *rnet = ndev->priv;
+
+ rio_add_outb_message(rnet->mport, rdev, 0, skb->data, skb->len);
+ rnet->tx_skb[rnet->tx_slot] = skb;
+
+ rnet->stats.tx_packets++;
+ rnet->stats.tx_bytes += skb->len;
+
+ if (++rnet->tx_cnt == RIONET_TX_RING_SIZE)
+ netif_stop_queue(ndev);
+
+ if (++rnet->tx_slot == RIONET_TX_RING_SIZE)
+ rnet->tx_slot = 0;
+
+ if (netif_msg_tx_queued(rnet))
+ printk(KERN_INFO "%s: queued skb %8.8x len %8.8x\n", DRV_NAME,
+ (u32) skb, skb->len);
+
+ return 0;
+}
+
+static int rionet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+{
+ int i;
+ struct rionet_private *rnet = ndev->priv;
+ struct ethhdr *eth = (struct ethhdr *)skb->data;
+ u16 destid;
+
+ spin_lock_irq(&rnet->lock);
+
+ if ((rnet->tx_cnt + 1) > RIONET_TX_RING_SIZE) {
+ netif_stop_queue(ndev);
+ spin_unlock_irq(&rnet->lock);
+ return -EBUSY;
+ }
+
+ if (eth->h_dest[0] & 0x01) {
+ /*
+ * XXX Need to delay queuing if ring max is reached,
+ * flush additional packets in tx_event() before
+ * awakening the queue. We can easily exceed ring
+ * size with a large number of nodes or even a
+ * small number where the ring is relatively full
+ * on entrance to hard_start_xmit.
+ */
+ for (i = 0; i < RIO_MAX_ROUTE_ENTRIES; i++)
+ if (rionet_active[i])
+ rionet_queue_tx_msg(skb, ndev,
+ rionet_active[i]);
+ } else if (RIONET_MAC_MATCH(eth->h_dest)) {
+ destid = RIONET_GET_DESTID(eth->h_dest);
+ if (rionet_active[destid])
+ rionet_queue_tx_msg(skb, ndev, rionet_active[destid]);
+ }
+
+ spin_unlock_irq(&rnet->lock);
+
+ return 0;
+}
+
+static int rionet_set_mac_address(struct net_device *ndev, void *p)
+{
+ struct sockaddr *addr = p;
+
+ if (!is_valid_ether_addr(addr->sa_data))
+ return -EADDRNOTAVAIL;
+
+ memcpy(ndev->dev_addr, addr->sa_data, ndev->addr_len);
+
+ return 0;
+}
+
+static int rionet_change_mtu(struct net_device *ndev, int new_mtu)
+{
+ struct rionet_private *rnet = ndev->priv;
+
+ if (netif_msg_drv(rnet))
+ printk(KERN_WARNING
+ "%s: rionet_change_mtu(): not implemented\n", DRV_NAME);
+
+ return 0;
+}
+
+static void rionet_set_multicast_list(struct net_device *ndev)
+{
+ struct rionet_private *rnet = ndev->priv;
+
+ if (netif_msg_drv(rnet))
+ printk(KERN_WARNING
+ "%s: rionet_set_multicast_list(): not implemented\n",
+ DRV_NAME);
+}
+
+static void rionet_dbell_event(struct rio_mport *mport, u16 sid, u16 tid,
+ u16 info)
+{
+ struct net_device *ndev = sndev;
+ struct rionet_private *rnet = ndev->priv;
+ struct rionet_peer *peer;
+
+ if (netif_msg_intr(rnet))
+ printk(KERN_INFO "%s: doorbell sid %4.4x tid %4.4x info %4.4x",
+ DRV_NAME, sid, tid, info);
+ if (info == RIONET_DOORBELL_JOIN) {
+ if (!rionet_active[sid]) {
+ list_for_each_entry(peer, &rionet_peers, node) {
+ if (peer->rdev->destid == sid)
+ rionet_active[sid] = peer->rdev;
+ }
+ rio_mport_send_doorbell(mport, sid,
+ RIONET_DOORBELL_JOIN);
+ }
+ } else if (info == RIONET_DOORBELL_LEAVE) {
+ rionet_active[sid] = NULL;
+ } else {
+ if (netif_msg_intr(rnet))
+ printk(KERN_WARNING "%s: unhandled doorbell\n",
+ DRV_NAME);
+ }
+}
+
+static void rionet_inb_msg_event(struct rio_mport *mport, int mbox, int slot)
+{
+ int n;
+ struct net_device *ndev = sndev;
+ struct rionet_private *rnet = (struct rionet_private *)ndev->priv;
+
+ if (netif_msg_intr(rnet))
+ printk(KERN_INFO "%s: inbound message event, mbox %d slot %d\n",
+ DRV_NAME, mbox, slot);
+
+ spin_lock(&rnet->lock);
+ if ((n = rionet_rx_clean(ndev)) != rnet->rx_slot)
+ rionet_rx_fill(ndev, n);
+ spin_unlock(&rnet->lock);
+}
+
+static void rionet_outb_msg_event(struct rio_mport *mport, int mbox, int slot)
+{
+ struct net_device *ndev = sndev;
+ struct rionet_private *rnet = ndev->priv;
+
+ spin_lock(&rnet->lock);
+
+ if (netif_msg_intr(rnet))
+ printk(KERN_INFO
+ "%s: outbound message event, mbox %d slot %d\n",
+ DRV_NAME, mbox, slot);
+
+ while (rnet->tx_cnt && (rnet->ack_slot != slot)) {
+ /* dma unmap single */
+ dev_kfree_skb_irq(rnet->tx_skb[rnet->ack_slot]);
+ rnet->tx_skb[rnet->ack_slot] = NULL;
+ if (++rnet->ack_slot == RIONET_TX_RING_SIZE)
+ rnet->ack_slot = 0;
+ rnet->tx_cnt--;
+ }
+
+ if (rnet->tx_cnt < RIONET_TX_RING_SIZE)
+ netif_wake_queue(ndev);
+
+ spin_unlock(&rnet->lock);
+}
+
+static int rionet_open(struct net_device *ndev)
+{
+ int i, rc = 0;
+ struct rionet_peer *peer, *tmp;
+ u32 pwdcsr;
+ struct rionet_private *rnet = ndev->priv;
+
+ if (netif_msg_ifup(rnet))
+ printk(KERN_INFO "%s: open\n", DRV_NAME);
+
+ if ((rc = rio_request_inb_dbell(rnet->mport,
+ RIONET_DOORBELL_JOIN,
+ RIONET_DOORBELL_LEAVE,
+ rionet_dbell_event)) < 0)
+ goto out;
+
+ if ((rc = rio_request_inb_mbox(rnet->mport,
+ RIONET_MAILBOX,
+ RIONET_RX_RING_SIZE,
+ rionet_inb_msg_event)) < 0)
+ goto out;
+
+ if ((rc = rio_request_outb_mbox(rnet->mport,
+ RIONET_MAILBOX,
+ RIONET_TX_RING_SIZE,
+ rionet_outb_msg_event)) < 0)
+ goto out;
+
+ /* Initialize inbound message ring */
+ for (i = 0; i < RIONET_RX_RING_SIZE; i++)
+ rnet->rx_skb[i] = NULL;
+ rnet->rx_slot = 0;
+ rionet_rx_fill(ndev, 0);
+
+ rnet->tx_slot = 0;
+ rnet->tx_cnt = 0;
+ rnet->ack_slot = 0;
+
+ spin_lock_init(&rnet->lock);
+
+ rnet->msg_enable = RIONET_DEFAULT_MSGLEVEL;
+
+ netif_carrier_on(ndev);
+ netif_start_queue(ndev);
+
+ list_for_each_entry_safe(peer, tmp, &rionet_peers, node) {
+ if (!(peer->res = rio_request_outb_dbell(peer->rdev,
+ RIONET_DOORBELL_JOIN,
+ RIONET_DOORBELL_LEAVE)))
+ {
+ printk(KERN_ERR "%s: error requesting doorbells\n",
+ DRV_NAME);
+ continue;
+ }
+
+ /*
+ * If device has initialized inbound doorbells,
+ * send a join message
+ */
+ rio_read_config_32(peer->rdev, RIO_WRITE_PORT_CSR, &pwdcsr);
+ if (pwdcsr & RIO_DOORBELL_AVAIL)
+ rio_send_doorbell(peer->rdev, RIONET_DOORBELL_JOIN);
+ }
+
+ out:
+ return rc;
+}
+
+static int rionet_close(struct net_device *ndev)
+{
+ struct rionet_private *rnet = (struct rionet_private *)ndev->priv;
+ struct rionet_peer *peer, *tmp;
+ int i;
+
+ if (netif_msg_ifup(rnet))
+ printk(KERN_INFO "%s: close\n", DRV_NAME);
+
+ netif_stop_queue(ndev);
+ netif_carrier_off(ndev);
+
+ for (i = 0; i < RIONET_RX_RING_SIZE; i++)
+ if (rnet->rx_skb[i])
+ kfree_skb(rnet->rx_skb[i]);
+
+ list_for_each_entry_safe(peer, tmp, &rionet_peers, node) {
+ if (rionet_active[peer->rdev->destid]) {
+ rio_send_doorbell(peer->rdev, RIONET_DOORBELL_LEAVE);
+ rionet_active[peer->rdev->destid] = NULL;
+ }
+ rio_release_outb_dbell(peer->rdev, peer->res);
+ }
+
+ rio_release_inb_dbell(rnet->mport, RIONET_DOORBELL_JOIN,
+ RIONET_DOORBELL_LEAVE);
+ rio_release_inb_mbox(rnet->mport, RIONET_MAILBOX);
+ rio_release_outb_mbox(rnet->mport, RIONET_MAILBOX);
+
+ return 0;
+}
+
+static void rionet_remove(struct rio_dev *rdev)
+{
+ struct net_device *ndev = NULL;
+ struct rionet_peer *peer, *tmp;
+
+ unregister_netdev(ndev);
+ kfree(ndev);
+
+ list_for_each_entry_safe(peer, tmp, &rionet_peers, node) {
+ list_del(&peer->node);
+ kfree(peer);
+ }
+}
+
+static int rionet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
+{
+ return -EOPNOTSUPP;
+}
+
+static void rionet_get_drvinfo(struct net_device *ndev,
+ struct ethtool_drvinfo *info)
+{
+ struct rionet_private *rnet = ndev->priv;
+
+ strcpy(info->driver, DRV_NAME);
+ strcpy(info->version, DRV_VERSION);
+ strcpy(info->fw_version, "n/a");
+ sprintf(info->bus_info, "RIO master port %d", rnet->mport->id);
+}
+
+static u32 rionet_get_msglevel(struct net_device *ndev)
+{
+ struct rionet_private *rnet = ndev->priv;
+
+ return rnet->msg_enable;
+}
+
+static void rionet_set_msglevel(struct net_device *ndev, u32 value)
+{
+ struct rionet_private *rnet = ndev->priv;
+
+ rnet->msg_enable = value;
+}
+
+static u32 rionet_get_link(struct net_device *ndev)
+{
+ return netif_carrier_ok(ndev);
+}
+
+static struct ethtool_ops rionet_ethtool_ops = {
+ .get_drvinfo = rionet_get_drvinfo,
+ .get_msglevel = rionet_get_msglevel,
+ .set_msglevel = rionet_set_msglevel,
+ .get_link = rionet_get_link,
+};
+
+static int rionet_setup_netdev(struct rio_mport *mport)
+{
+ int rc = 0;
+ struct net_device *ndev = NULL;
+ struct rionet_private *rnet;
+ u16 device_id;
+
+ /* Allocate our net_device structure */
+ ndev = alloc_etherdev(sizeof(struct rionet_private));
+ if (ndev == NULL) {
+ printk(KERN_INFO "%s: could not allocate ethernet device.\n",
+ DRV_NAME);
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ /*
+ * XXX hack, store point a static at ndev so we can get it...
+ * Perhaps need an array of these that the handler can
+ * index via the mbox number.
+ */
+ sndev = ndev;
+
+ /* Set up private area */
+ rnet = (struct rionet_private *)ndev->priv;
+ rnet->mport = mport;
+
+ /* Set the default MAC address */
+ device_id = rio_local_get_device_id(mport);
+ ndev->dev_addr[0] = 0x00;
+ ndev->dev_addr[1] = 0x01;
+ ndev->dev_addr[2] = 0x00;
+ ndev->dev_addr[3] = 0x01;
+ ndev->dev_addr[4] = device_id >> 8;
+ ndev->dev_addr[5] = device_id & 0xff;
+
+ /* Fill in the driver function table */
+ ndev->open = &rionet_open;
+ ndev->hard_start_xmit = &rionet_start_xmit;
+ ndev->stop = &rionet_close;
+ ndev->get_stats = &rionet_stats;
+ ndev->change_mtu = &rionet_change_mtu;
+ ndev->set_mac_address = &rionet_set_mac_address;
+ ndev->set_multicast_list = &rionet_set_multicast_list;
+ ndev->do_ioctl = &rionet_ioctl;
+ SET_ETHTOOL_OPS(ndev, &rionet_ethtool_ops);
+
+ ndev->mtu = RIO_MAX_MSG_SIZE - 14;
+
+ SET_MODULE_OWNER(ndev);
+
+ rc = register_netdev(ndev);
+ if (rc != 0)
+ goto out;
+
+ printk("%s: %s %s Version %s, MAC %02x:%02x:%02x:%02x:%02x:%02x\n",
+ ndev->name,
+ DRV_NAME,
+ DRV_DESC,
+ DRV_VERSION,
+ ndev->dev_addr[0], ndev->dev_addr[1], ndev->dev_addr[2],
+ ndev->dev_addr[3], ndev->dev_addr[4], ndev->dev_addr[5]);
+
+ out:
+ return rc;
+}
+
+/*
+ * XXX Make multi-net safe
+ */
+static int rionet_probe(struct rio_dev *rdev, const struct rio_device_id *id)
+{
+ int rc = -ENODEV;
+ u32 lpef, lsrc_ops, ldst_ops;
+ struct rionet_peer *peer;
+
+ /* If local device is not rionet capable, give up quickly */
+ if (!rionet_capable)
+ goto out;
+
+ /*
+ * First time through, make sure local device is rionet
+ * capable, setup netdev, and set flags so this is skipped
+ * on later probes
+ */
+ if (!rionet_check) {
+ rio_local_read_config_32(rdev->net->hport, RIO_PEF_CAR, &lpef);
+ rio_local_read_config_32(rdev->net->hport, RIO_SRC_OPS_CAR,
+ &lsrc_ops);
+ rio_local_read_config_32(rdev->net->hport, RIO_DST_OPS_CAR,
+ &ldst_ops);
+ if (!is_rionet_capable(lpef, lsrc_ops, ldst_ops)) {
+ printk(KERN_ERR
+ "%s: local device is not network capable\n",
+ DRV_NAME);
+ rionet_check = 1;
+ rionet_capable = 0;
+ goto out;
+ }
+
+ rc = rionet_setup_netdev(rdev->net->hport);
+ rionet_check = 1;
+ }
+
+ /*
+ * If the remote device has mailbox/doorbell capabilities,
+ * add it to the peer list.
+ */
+ if (dev_rionet_capable(rdev)) {
+ if (!(peer = kmalloc(sizeof(struct rionet_peer), GFP_KERNEL))) {
+ rc = -ENOMEM;
+ goto out;
+ }
+ peer->rdev = rdev;
+ list_add_tail(&peer->node, &rionet_peers);
+ }
+
+ out:
+ return rc;
+}
+
+static struct rio_device_id rionet_id_table[] = {
+ {RIO_DEVICE(RIO_ANY_ID, RIO_ANY_ID)}
+};
+
+static struct rio_driver rionet_driver = {
+ .name = "rionet",
+ .id_table = rionet_id_table,
+ .probe = rionet_probe,
+ .remove = rionet_remove,
+};
+
+static int __init rionet_init(void)
+{
+ return rio_register_driver(&rionet_driver);
+}
+
+static void __exit rionet_exit(void)
+{
+ rio_unregister_driver(&rionet_driver);
+}
+
+module_init(rionet_init);
+module_exit(rionet_exit);
^ permalink raw reply
* Re: 2.6.12-rcx networking oops
From: Phil Oester @ 2005-06-01 17:00 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, akpm
In-Reply-To: <20050601054955.GA2625@gondor.apana.org.au>
On Wed, Jun 01, 2005 at 03:49:55PM +1000, Herbert Xu wrote:
> This looks like stack overflow. %esi is meant to be "res" which is
> a local variable. As you can see, it's pointing below %esp and
> threadinfo.
Ok, so I enabled DEBUG_STACKOVERFLOW in addition to CONFIG_DEBUG_SLAB
and CONFIG_DEBUG_PAGEALLOC, and got the below today...so maybe it
is a slab issue?
0xc0238cdd is in dst_alloc (net/core/dst.c:124).
119 if (ops->gc && atomic_read(&ops->entries) > ops->gc_thresh) {
120 if (ops->gc())
121 return NULL;
122 }
123 dst = kmem_cache_alloc(ops->kmem_cachep, SLAB_ATOMIC);
0xc013912b is at mm/slab.c:3077.
3072 size = kmem_cache_size(c);
3073 local_irq_restore(flags);
3074 }
3075
3076 return size;
3077 }
Phil
invalid operand: 0000 [#1]
SMP DEBUG_PAGEALLOC
CPU: 1
EIP: 0060:[<c013912b>] Not tainted VLI
EFLAGS: 00016292 (2.6.12-rc5-git5)
EIP is at ksize+0x7b/0x100
eax: c0238cdd ebx: f7ba9c20 ecx: f7babf78 edx: dcc59000
esi: 00000020 edi: 0000e3ba ebp: c0338d98 esp: c0338d88
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c0338000 task=c1989b00)
Stack: 00000000 04000000 c02d1a00 ffffff97 c0338db0 c0238cdd c0338e58 04000000
00000000 ffffff97 c0338eb4 c0245cb7 00000002 f7b01000 c0338dec c0338df0
f7318ef8 00000000 00000000 00000001 f72dbef8 0000a704 103c243b f27ceec0
Call Trace:
[<c010389a>] show_stack+0x7a/0x90
[<c0103a1d>] show_registers+0x14d/0x1b0
[<c0103c29>] die+0xf9/0x180
[<c0103d50>] do_trap+0xa0/0xb0
[<c0104039>] do_invalid_op+0xa9/0xc0
[<c01034e3>] error_code+0x4f/0x54
[<c0238cdd>] dst_alloc+0x2d/0xa0
[<c0245cb7>] ip_route_input_slow+0x4a7/0x840
[<c02460ea>] ip_route_input+0x9a/0x160
[<c02481c0>] ip_rcv+0x3b0/0x4d0
[<c02357aa>] netif_receive_skb+0x13a/0x1a0
[<c01fa1d0>] e1000_clean_rx_irq+0x180/0x4d0
[<c01f9a10>] e1000_clean+0x40/0xe0
[<c02359c0>] net_rx_action+0x90/0x130
[<c011a8c4>] __do_softirq+0xd4/0xf0
[<c0104fc2>] do_softirq+0x52/0x70
=======================
[<c011a9aa>] irq_exit+0x3a/0x40
[<c0104e98>] do_IRQ+0x68/0xa0
[<c010338a>] common_interrupt+0x1a/0x20
[<c0100a8b>] cpu_idle+0x7b/0x80
[<c0305c13>] start_secondary+0x73/0x90
[<00000000>] stext+0x3feffd6c/0xc
[<c198afb4>] 0xc198afb4
Code: 8d 05 0c e2 34 c0 e8 e9 25 15 00 e9 96 dd ff ff 8d 05 0c e2 34 c0 e8 a9 25 15 00 e9 00 e2 ff
ff 8d 05 0c e2 34 c0 e8 c9 25 15 00 <e9> 23 e2 ff ff 8d 05 0c e2 34 c0 e8 89 25 15 00 e9 84 e2 ff ff
<0>Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* Re: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks
From: Trent Jaeger @ 2005-06-01 13:59 UTC (permalink / raw)
To: James Morris; +Cc: chrisw, latten, netdev, sds, serue
In-Reply-To: <Xine.LNX.4.44.0505310006060.28060-100000@thoron.boston.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]
OK.
Thanks for the detailed comments.
I will review and get back with comments and mods (probably next week).
Regards,
Trent.
------------------------------------------------------------
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532
(914) 784-7225, FAX (914) 784-7225
James Morris <jmorris@redhat.com>
05/31/2005 12:15 AM
To: Trent Jaeger/Watson/IBM@IBMUS
cc: netdev@oss.sgi.com, <chrisw@osdl.org>,
serue@us.ltcfwd.linux.ibm.com, <latten@austin.ibm.com>,
<sds@tycho.nsa.gov>
Subject: Re: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks
On Tue, 17 May 2005, jaegert wrote:
Ok, my last review in this iteration.
> @@ -984,6 +1029,13 @@ static struct xfrm_state * pfkey_msg2xfr
> x->lft.soft_add_expires_seconds =
lifetime->sadb_lifetime_addtime;
> x->lft.soft_use_expires_seconds =
lifetime->sadb_lifetime_usetime;
> }
> +
> + sec_ctx = (struct sadb_x_sec_ctx *)
ext_hdrs[SADB_X_EXT_SEC_CTX-1];
> + if (sec_ctx != NULL) {
> + if (security_xfrm_state_alloc(x, sec_ctx))
> + goto out;
You should propagate the return value of security_xfrm_state_alloc() here
by assigning it to err.
> -selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o
> +selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o nethooks.o
What about making nethooks.o (or whatever it'll be called) conditionally
compiled via CONFIG_SECURITY_NETWORK_XFRM ? (see netif.o)
> + * ISSUES:
> + * 1. Caching packets, so they are not dropped during negotiation
This needs to be done for IPsec in general, not sure what the status is.
> + * 2. Emulating a reasonable SO_PEERSEC across machines
This may not be too difficult if we limit this to connected TCP sockets.
> + * 3. Testing sk_policy setting with context
What does this mean?
Overall, this looks like a really good approach to the problem.
- James
--
James Morris
<jmorris@redhat.com>
[-- Attachment #2: Type: text/html, Size: 3694 bytes --]
^ permalink raw reply
* Unable to handle kernel paging request at virtual address 04000460
From: raghunathan.venkatesan @ 2005-06-01 11:31 UTC (permalink / raw)
To: linux-net, netdev, linux
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
Hi Everyone,
We are facing the following crash in custom Linux 2.4.26 kernel, when we
run a netperf TCP Stream (sizes varying from 64 to 32586 bytes) test
over an IPSEC tunnel created between a host and a VPN server through our
box. This is a Au1550 MIPS32 based board (DB1550 Cabernet board from
AMD). We observe that crash happens randomly (the PrId keeps changing at
each crash), because of burstiness in the netperf tool generated
traffic. Please look into the following capture below. I'd like some
help in debugging this issue. The same set of IPSEC drivers (not from
Linux) works fine on a custom Linux 2.4.25 based kernel. We debugged the
Oops traces and found that all problems arise in skbuff (donno where in
skbuff). Is there a patch that needs to be applied for Linux 2.4.26 ?
Thanks & Regards,
Raghu Venkatesan
Project Manager (E & PE, Semiconductor & Access),
CDC2, Sozhanganallur,
Chennai - 600 119, INDIA
+91 -44-24500200 Ext. 2643
raghunathan.venkatesan@wipro.com
[-- Attachment #2: recent.cap_send1.oops --]
[-- Type: application/octet-stream, Size: 5317 bytes --]
ksymoops 2.4.9 on i686 2.4.22-1.2115.nptl. Options used
-v /home/amd/project/amd/kernel/vmlinux (default)
-K (specified)
-l /proc/modules (default)
-o /home/amd/project/amd/filesystem/usr/lib/modules/ (default)
-m /home/amd/project/amd/kernel/System.map (default)
-t elf32-littlemips -a mips:4600
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel paging request at virtual address 020004d4, epc == 8024af6c, ra == 8024b094
Oops in fault.c::do_page_fault, line 206:
$0 : 00000000 1000fc00 8abbb600 02000460 02000460 8abbb5ec 00000000 000005ec
$8 : 5ad3436e 8abbbdec b3de5d71 56736988 0783fdfb 80323858 80323804 24e12ae5
$16: 02000460 00000001 8abbb800 00000600 00000cfc 000005dc 00000014 00003408
$24: 00000000 2aea3c70 80322000 80323a28 0000341c 8024b094
Hi : 00000000
Lo : 00000800
epc : 8024af6c Not tainted
Status: 1000fc03
Cause : 00800008
Process swapper (pid: 0, stackpage=80322000)
Stack: 8b962480 00000000 00000000 00000000 00000800 8b6af460 8024b094
8b6af460 8abbb800 00000600 00000cfc 000005dc 00000800 8b6af460 8024b7cc
8024b7b0 24e12ae5 80323858 80323804 c01c2050 8b6af460 803a0400 000005c8
812be300 802501d4 000005dc 00000014 00002e40 00000000 2aea3c70 8b6af460
8aea1160 000005c8 8026a9e8 00002e54 8026a184 1000fc03 00000000 8b6af460
8abbb010 ...
Call Trace: [<8024b094>] [<8024b7cc>] [<8024b7b0>] [<802501d4>] [<8026a9e8>]
[<8026a184>] [<8026a30c>] [<8026a1dc>] [<8026a90c>] [<8026a90c>] [<8029c418>]
[<8026a90c>] [<8026a90c>] [<8025a484>] [<8026a90c>] [<8026a90c>] [<8025a948>]
[<802da0e0>] [<8026a90c>] [<8026a8d4>] [<8026a90c>] [<8026a30c>] [<8026a184>]
[<80267130>] [<802671b0>] [<8026a744>] [<8025a98c>] [<8029ed88>] [<80267130>]
[<8029fd34>] [<8026706c>] [<80267130>] [<802657f8>] [<80265a20>] [<8025a484>]
[<c01ce2a8>] [<802657f8>] [<802657f8>] [<8025a98c>] [<8025a948>] ...
Warning (Oops_trace_line): garbage '...' at end of trace line ignored
Code: 8c500008 ac400008 02002021 <8c820074> 10510009 8e100000 c0830074 00711023 e0820074
>>RA; 000000008024b094 <skb_release_data+b0/bc>
>>$13; 0000000080323858 <init_task_union+1858/2000>
>>$14; 0000000080323804 <init_task_union+1804/2000>
>>$28; 0000000080322000 <init_task_union+0/2000>
>>$29; 0000000080323a28 <init_task_union+1a28/2000>
>>$31; 000000008024b094 <skb_release_data+b0/bc>
>>PC; 000000008024af6c <skb_drop_fraglist+34/74> <=====
Trace; 000000008024b094 <skb_release_data+b0/bc>
Trace; 000000008024b7cc <skb_linearize+c4/14c>
Trace; 000000008024b7b0 <skb_linearize+a8/14c>
Trace; 00000000802501d4 <dev_queue_xmit+50/3b8>
Trace; 000000008026a9e8 <ip_finish_output2+ec/150>
Trace; 000000008026a184 <ip_fragment+240/500>
Trace; 000000008026a30c <ip_fragment+3c8/500>
Trace; 000000008026a1dc <ip_fragment+298/500>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008029c418 <ip_refrag+68/74>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008025a484 <nf_iterate+94/114>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008025a948 <nf_hook_slow+128/1f8>
Trace; 00000000802da0e0 <memset+0/1c>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008026a8d4 <ip_finish_output+1a0/1a4>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008026a30c <ip_fragment+3c8/500>
Trace; 000000008026a184 <ip_fragment+240/500>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 00000000802671b0 <ip_forward_finish+90/a0>
Trace; 000000008026a744 <ip_finish_output+10/1a4>
Trace; 000000008025a98c <nf_hook_slow+16c/1f8>
Trace; 000000008029ed88 <ip_ct_refresh+84/b8>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 000000008029fd34 <icmp_packet+98/9c>
Trace; 000000008026706c <__gnu_compiled_c+26c/320>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 0000000080265a20 <ip_rcv_finish+238/2a8>
Trace; 000000008025a484 <nf_iterate+94/114>
Trace; 00000000c01ce2a8 <END_OF_CODE+3fe3baa8/????>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 000000008025a98c <nf_hook_slow+16c/1f8>
Trace; 000000008025a948 <nf_hook_slow+128/1f8>
Code; 000000008024af60 <skb_drop_fraglist+28/74>
00000000 <_PC>:
Code; 000000008024af60 <skb_drop_fraglist+28/74>
0: 8c500008 lw s0,8(v0)
Code; 000000008024af64 <skb_drop_fraglist+2c/74>
4: ac400008 sw zero,8(v0)
Code; 000000008024af68 <skb_drop_fraglist+30/74>
8: 02002021 move a0,s0
Code; 000000008024af6c <skb_drop_fraglist+34/74> <=====
c: 8c820074 lw v0,116(a0) <=====
Code; 000000008024af70 <skb_drop_fraglist+38/74>
10: 10510009 beq v0,s1,38 <_PC+0x38>
Code; 000000008024af74 <skb_drop_fraglist+3c/74>
14: 8e100000 lw s0,0(s0)
Code; 000000008024af78 <skb_drop_fraglist+40/74>
18: c0830074 ll v1,116(a0)
Code; 000000008024af7c <skb_drop_fraglist+44/74>
1c: 00711023 subu v0,v1,s1
Code; 000000008024af80 <skb_drop_fraglist+48/74>
20: e0820074 sc v0,116(a0)
Kernel panic: Aiee, killing interrupt handler!
1 warning issued. Results may not be reliable.
[-- Attachment #3: recent.cap.oops --]
[-- Type: application/octet-stream, Size: 5334 bytes --]
ksymoops 2.4.9 on i686 2.4.22-1.2115.nptl. Options used
-v /home/amd/project/amd/kernel/vmlinux (default)
-K (specified)
-l /proc/modules (default)
-o /home/amd/project/amd/filesystem/usr/lib/modules/ (default)
-m /home/amd/project/amd/kernel/System.map (default)
-t elf32-littlemips -a mips:4600
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel paging request at virtual address 04000460, epc == 8024b20c, ra == 802c49f8
Oops in fault.c::do_page_fault, line 206:
$0 : 00000000 00000000 00000000 00000001 8b783580 00000000 04000460 00000001
$8 : 00000000 00000000 00000002 d3d0b000 80323b68 00000000 80323d60 7b7a7978
$16: 812beb20 812beb20 ffffffff 8bb0d800 803a0804 00000000 00000002 80323e10
$24: 00000000 2b00ac70 80322000 80323ad0 00002401 802c49f8
Hi : 00002091
Lo : d691285e
epc : 8024b20c Not tainted
Status: 1000fc03
Cause : 00800008
Process swapper (pid: 0, stackpage=80322000)
Stack: 00000000 8bb0d800 803a0804 00000000 812beb20 802c49f8 80107c28
00000000 00000000 00000000 812beb20 8124fc68 8b6af5a0 803a0800 00000004
80250088 00000000 00000000 00000000 00000000 812b6560 803a0800 8b6af5a0
803a0800 00000000 8025c3e0 00000000 00000000 80323c18 80369bf0 8034d7e8
803a0800 00000000 8025037c 8029c3ec 00000000 8b783580 8b6af5a0 0000000e
8b6af5a0 ...
Call Trace: [<802c49f8>] [<80107c28>] [<80250088>] [<8025c3e0>] [<8025037c>]
[<8029c3ec>] [<802573a8>] [<8025a484>] [<8026a90c>] [<8026a9e8>] [<8026a90c>]
[<8025a98c>] [<8025a948>] [<8026a90c>] [<802a3d98>] [<80267130>] [<8026a8d4>]
[<8026a90c>] [<802671c0>] [<80267130>] [<8025a98c>] [<8029cf50>] [<80267130>]
[<8029fd04>] [<8026706c>] [<80267130>] [<802657f8>] [<80265a20>] [<8025a484>]
[<c01ce2a8>] [<802657f8>] [<802657f8>] [<8025a98c>] [<8025a948>] [<802657f8>]
[<802655a0>] [<802657f8>] [<80250d48>] [<802e01f4>] [<80107c28>] ...
Warning (Oops_trace_line): garbage '...' at end of trace line ignored
Code: 8e06009c 10c0000e 24030001 <8cc20000> c0450000 00a32023 e0440000 1080fffc 00a32023
>>RA; 00000000802c49f8 <packet_rcv_spkt+29c/2b0>
>>$12; 0000000080323b68 <init_task_union+1b68/2000>
>>$14; 0000000080323d60 <init_task_union+1d60/2000>
>>$23; 0000000080323e10 <init_task_union+1e10/2000>
>>$28; 0000000080322000 <init_task_union+0/2000>
>>$29; 0000000080323ad0 <init_task_union+1ad0/2000>
>>$31; 00000000802c49f8 <packet_rcv_spkt+29c/2b0>
>>PC; 000000008024b20c <__kfree_skb+a4/130> <=====
Trace; 00000000802c49f8 <packet_rcv_spkt+29c/2b0>
Trace; 0000000080107c28 <do_gettimeofday+58/114>
Trace; 0000000080250088 <dev_queue_xmit_nit+bc/110>
Trace; 000000008025c3e0 <__gnu_compiled_c+70/14c>
Trace; 000000008025037c <dev_queue_xmit+1f8/3b8>
Trace; 000000008029c3ec <ip_refrag+3c/74>
Trace; 00000000802573a8 <neigh_resolve_output+1fc/29c>
Trace; 000000008025a484 <nf_iterate+94/114>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008026a9e8 <ip_finish_output2+ec/150>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008025a98c <nf_hook_slow+16c/1f8>
Trace; 000000008025a948 <nf_hook_slow+128/1f8>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 00000000802a3d98 <ipt_local_out_hook+4/8c>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 000000008026a8d4 <ip_finish_output+1a0/1a4>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 00000000802671c0 <ip_options_build+0/0>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 000000008025a98c <nf_hook_slow+16c/1f8>
Trace; 000000008029cf50 <death_by_timeout+3c/a8>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 000000008029fd04 <icmp_packet+68/9c>
Trace; 000000008026706c <__gnu_compiled_c+26c/320>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 0000000080265a20 <ip_rcv_finish+238/2a8>
Trace; 000000008025a484 <nf_iterate+94/114>
Trace; 00000000c01ce2a8 <END_OF_CODE+3fe3baa8/????>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 000000008025a98c <nf_hook_slow+16c/1f8>
Trace; 000000008025a948 <nf_hook_slow+128/1f8>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 00000000802655a0 <ip_rcv+510/578>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 0000000080250d48 <netif_receive_skb+270/2c0>
Trace; 00000000802e01f4 <au1000_IRQ+134/1a0>
Trace; 0000000080107c28 <do_gettimeofday+58/114>
Code; 000000008024b200 <__kfree_skb+98/130>
00000000 <_PC>:
Code; 000000008024b200 <__kfree_skb+98/130>
0: 8e06009c lw a2,156(s0)
Code; 000000008024b204 <__kfree_skb+9c/130>
4: 10c0000e beqz a2,40 <_PC+0x40>
Code; 000000008024b208 <__kfree_skb+a0/130>
8: 24030001 li v1,1
Code; 000000008024b20c <__kfree_skb+a4/130> <=====
c: 8cc20000 lw v0,0(a2) <=====
Code; 000000008024b210 <__kfree_skb+a8/130>
10: c0450000 ll a1,0(v0)
Code; 000000008024b214 <__kfree_skb+ac/130>
14: 00a32023 subu a0,a1,v1
Code; 000000008024b218 <__kfree_skb+b0/130>
18: e0440000 sc a0,0(v0)
Code; 000000008024b21c <__kfree_skb+b4/130>
1c: 1080fffc beqz a0,10 <_PC+0x10>
Code; 000000008024b220 <__kfree_skb+b8/130>
20: 00a32023 subu a0,a1,v1
Kernel panic: Aiee, killing interrupt handler!
1 warning issued. Results may not be reliable.
[-- Attachment #4: recent.cap_recv.oops --]
[-- Type: application/octet-stream, Size: 5074 bytes --]
ksymoops 2.4.9 on i686 2.4.22-1.2115.nptl. Options used
-v /home/amd/project/amd/kernel/vmlinux (default)
-K (specified)
-l /proc/modules (default)
-o /home/amd/project/amd/filesystem/usr/lib/modules/ (default)
-m /home/amd/project/amd/kernel/System.map (default)
-t elf32-littlemips -a mips:4600
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel paging request at virtual address 00003260, epc == 8024b20c, ra == 802c49f8
Oops in fault.c::do_page_fault, line 206:
$0 : 00000000 00000000 00000000 00000001 8b780760 00000000 00003260 00000001
$8 : 00000000 00000000 00000002 d3d0b000 c0115000 000014b8 8b9bfd28 7b7a7978
$16: 8b6b5460 8b6b5460 ffffffff 8b90f800 803a0804 00000000 00000002 8b9bfdd8
$24: 00000000 2acad550 8b9be000 8b9bfa98 0000479d 802c49f8
Hi : 00002361
Lo : 7650f108
epc : 8024b20c Not tainted
Status: 1000fc03
Cause : 00800008
Process voslog (pid: 134, stackpage=8b9be000)
Stack: 00000000 8b90f800 803a0804 00000000 8b6b5460 802c49f8 80107c28
00000000 00000000 00000000 8b6b5460 8124fc68 812bed00 803a0800 00000004
80250088 00000000 00000000 8029d380 00000000 812b6560 803a0800 812bed00
803a0800 00000000 8025c3e0 8026a90c 00000003 00000002 8029c3ac 8034d7e8
803a0800 00000000 8025037c 8029c3ec 00000000 8b780760 812bed00 0000000e
812bed00 ...
Call Trace: [<802c49f8>] [<80107c28>] [<80250088>] [<8029d380>] [<8025c3e0>]
[<8026a90c>] [<8029c3ac>] [<8025037c>] [<8029c3ec>] [<802573a8>] [<8025a484>]
[<8026a90c>] [<8026a9e8>] [<8026a90c>] [<8025a98c>] [<8025a948>] [<8026a90c>]
[<802a3d98>] [<80267130>] [<8026a8d4>] [<8026a90c>] [<802671c0>] [<80267130>]
[<8025a98c>] [<80267130>] [<8029fd34>] [<8026706c>] [<80267130>] [<802657f8>]
[<80265a20>] [<8025a484>] [<c01ce2a8>] [<802657f8>] [<802657f8>] [<8025a98c>]
[<8025a948>] [<802657f8>] [<802655a0>] [<802657f8>] [<8010133c>] ...
Warning (Oops_trace_line): garbage '...' at end of trace line ignored
Code: 8e06009c 10c0000e 24030001 <8cc20000> c0450000 00a32023 e0440000 1080fffc 00a32023
>>RA; 00000000802c49f8 <packet_rcv_spkt+29c/2b0>
>>$31; 00000000802c49f8 <packet_rcv_spkt+29c/2b0>
>>PC; 000000008024b20c <__kfree_skb+a4/130> <=====
Trace; 00000000802c49f8 <packet_rcv_spkt+29c/2b0>
Trace; 0000000080107c28 <do_gettimeofday+58/114>
Trace; 0000000080250088 <dev_queue_xmit_nit+bc/110>
Trace; 000000008029d380 <__ip_conntrack_confirm+238/2c8>
Trace; 000000008025c3e0 <__gnu_compiled_c+70/14c>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008029c3ac <ip_confirm+48/4c>
Trace; 000000008025037c <dev_queue_xmit+1f8/3b8>
Trace; 000000008029c3ec <ip_refrag+3c/74>
Trace; 00000000802573a8 <neigh_resolve_output+1fc/29c>
Trace; 000000008025a484 <nf_iterate+94/114>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008026a9e8 <ip_finish_output2+ec/150>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008025a98c <nf_hook_slow+16c/1f8>
Trace; 000000008025a948 <nf_hook_slow+128/1f8>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 00000000802a3d98 <ipt_local_out_hook+4/8c>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 000000008026a8d4 <ip_finish_output+1a0/1a4>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 00000000802671c0 <ip_options_build+0/0>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 000000008025a98c <nf_hook_slow+16c/1f8>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 000000008029fd34 <icmp_packet+98/9c>
Trace; 000000008026706c <__gnu_compiled_c+26c/320>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 0000000080265a20 <ip_rcv_finish+238/2a8>
Trace; 000000008025a484 <nf_iterate+94/114>
Trace; 00000000c01ce2a8 <END_OF_CODE+3fe3baa8/????>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 000000008025a98c <nf_hook_slow+16c/1f8>
Trace; 000000008025a948 <nf_hook_slow+128/1f8>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 00000000802655a0 <ip_rcv+510/578>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 000000008010133c <do_IRQ+f4/118>
Code; 000000008024b200 <__kfree_skb+98/130>
00000000 <_PC>:
Code; 000000008024b200 <__kfree_skb+98/130>
0: 8e06009c lw a2,156(s0)
Code; 000000008024b204 <__kfree_skb+9c/130>
4: 10c0000e beqz a2,40 <_PC+0x40>
Code; 000000008024b208 <__kfree_skb+a0/130>
8: 24030001 li v1,1
Code; 000000008024b20c <__kfree_skb+a4/130> <=====
c: 8cc20000 lw v0,0(a2) <=====
Code; 000000008024b210 <__kfree_skb+a8/130>
10: c0450000 ll a1,0(v0)
Code; 000000008024b214 <__kfree_skb+ac/130>
14: 00a32023 subu a0,a1,v1
Code; 000000008024b218 <__kfree_skb+b0/130>
18: e0440000 sc a0,0(v0)
Code; 000000008024b21c <__kfree_skb+b4/130>
1c: 1080fffc beqz a0,10 <_PC+0x10>
Code; 000000008024b220 <__kfree_skb+b8/130>
20: 00a32023 subu a0,a1,v1
Kernel panic: Aiee, killing interrupt handler!
1 warning issued. Results may not be reliable.
[-- Attachment #5: recent.cap_send.oops --]
[-- Type: application/octet-stream, Size: 5205 bytes --]
ksymoops 2.4.9 on i686 2.4.22-1.2115.nptl. Options used
-v /home/amd/project/amd/kernel/vmlinux (default)
-K (specified)
-l /proc/modules (default)
-o /home/amd/project/amd/filesystem/usr/lib/modules/ (default)
-m /home/amd/project/amd/kernel/System.map (default)
-t elf32-littlemips -a mips:4600
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel paging request at virtual address 000032d4, epc == 8024af6c, ra == 8024b094
Oops in fault.c::do_page_fault, line 206:
$0 : 00000000 1000fc00 8ac81e00 00003260 00003260 00000000 00000000 8b38b340
$8 : 00000030 802da1a0 00000010 bfbebdbc a3a2a1a0 00000000 8ab79de8 a7a6a5a4
$16: 00003260 00000001 8aea8260 c017294c 0000000f 8024b178 c0167ab8 c0172950
$24: 00000010 0040e0f0 8ab78000 8ab79a68 c01727d8 8024b094
Hi : 00000000
Lo : 0000000b
epc : 8024af6c Not tainted
Status: 1000fc03
Cause : 00800008
Process mdm-wipro-no-de (pid: 410, stackpage=8ab78000)
Stack: 8ab79ad8 80369bf0 00000004 8025a484 8b6b5460 8b6b5460 8024b094
fffbc473 8026a90c 803a0400 812bea80 803a0400 8b6b5460 8b38b360 8024b0c4
00000000 00000002 000040d2 802da0e0 8ab79c58 8b6b5460 8024b298 812b6460
803a0400 803a0400 8ab79ad8 8b6b5460 c0171f58 812bebc0 803906a8 00000020
8024ae38 8b6b5780 8aac40f6 8b428d60 00000000 812bebc0 8aac0010 8aea8260
000040d2 ...
Call Trace: [<8025a484>] [<8024b094>] [<8026a90c>] [<8024b0c4>] [<802da0e0>]
[<8024b298>] [<c0171f58>] [<8024ae38>] [<802d9d80>] [<c0171e10>] [<8026a90c>]
[<c0172414>] [<c01740e8>] [<8025a484>] [<8026a90c>] [<8026a90c>] [<8025a948>]
[<802da0e0>] [<8026a90c>] [<c01751dc>] [<8026a8d4>] [<8026a90c>] [<8026a30c>]
[<8026a184>] [<80267130>] [<802671b0>] [<8026a744>] [<8025a98c>] [<80267130>]
[<8026706c>] [<80267130>] [<802657f8>] [<80265a20>] [<8025a484>] [<c01ce2a8>]
[<802657f8>] [<802657f8>] [<8025a98c>] [<8025a948>] [<802657f8>] ...
Warning (Oops_trace_line): garbage '...' at end of trace line ignored
Code: 8c500008 ac400008 02002021 <8c820074> 10510009 8e100000 c0830074 00711023 e0820074
>>RA; 000000008024b094 <skb_release_data+b0/bc>
>>$9; 00000000802da1a0 <memset_partial+24/6c>
>>$21; 000000008024b178 <__kfree_skb+10/130>
>>$31; 000000008024b094 <skb_release_data+b0/bc>
>>PC; 000000008024af6c <skb_drop_fraglist+34/74> <=====
Trace; 000000008025a484 <nf_iterate+94/114>
Trace; 000000008024b094 <skb_release_data+b0/bc>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008024b0c4 <kfree_skbmem+24/c8>
Trace; 00000000802da0e0 <memset+0/1c>
Trace; 000000008024b298 <skb_clone+0/250>
Trace; 00000000c0171f58 <END_OF_CODE+3fddf758/????>
Trace; 000000008024ae38 <alloc_skb+160/260>
Trace; 00000000802d9d80 <memcpy+0/4>
Trace; 00000000c0171e10 <END_OF_CODE+3fddf610/????>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 00000000c0172414 <END_OF_CODE+3fddfc14/????>
Trace; 00000000c01740e8 <END_OF_CODE+3fde18e8/????>
Trace; 000000008025a484 <nf_iterate+94/114>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008025a948 <nf_hook_slow+128/1f8>
Trace; 00000000802da0e0 <memset+0/1c>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 00000000c01751dc <END_OF_CODE+3fde29dc/????>
Trace; 000000008026a8d4 <ip_finish_output+1a0/1a4>
Trace; 000000008026a90c <ip_finish_output2+10/150>
Trace; 000000008026a30c <ip_fragment+3c8/500>
Trace; 000000008026a184 <ip_fragment+240/500>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 00000000802671b0 <ip_forward_finish+90/a0>
Trace; 000000008026a744 <ip_finish_output+10/1a4>
Trace; 000000008025a98c <nf_hook_slow+16c/1f8>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 000000008026706c <__gnu_compiled_c+26c/320>
Trace; 0000000080267130 <ip_forward_finish+10/a0>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 0000000080265a20 <ip_rcv_finish+238/2a8>
Trace; 000000008025a484 <nf_iterate+94/114>
Trace; 00000000c01ce2a8 <END_OF_CODE+3fe3baa8/????>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Trace; 000000008025a98c <nf_hook_slow+16c/1f8>
Trace; 000000008025a948 <nf_hook_slow+128/1f8>
Trace; 00000000802657f8 <ip_rcv_finish+10/2a8>
Code; 000000008024af60 <skb_drop_fraglist+28/74>
00000000 <_PC>:
Code; 000000008024af60 <skb_drop_fraglist+28/74>
0: 8c500008 lw s0,8(v0)
Code; 000000008024af64 <skb_drop_fraglist+2c/74>
4: ac400008 sw zero,8(v0)
Code; 000000008024af68 <skb_drop_fraglist+30/74>
8: 02002021 move a0,s0
Code; 000000008024af6c <skb_drop_fraglist+34/74> <=====
c: 8c820074 lw v0,116(a0) <=====
Code; 000000008024af70 <skb_drop_fraglist+38/74>
10: 10510009 beq v0,s1,38 <_PC+0x38>
Code; 000000008024af74 <skb_drop_fraglist+3c/74>
14: 8e100000 lw s0,0(s0)
Code; 000000008024af78 <skb_drop_fraglist+40/74>
18: c0830074 ll v1,116(a0)
Code; 000000008024af7c <skb_drop_fraglist+44/74>
1c: 00711023 subu v0,v1,s1
Code; 000000008024af80 <skb_drop_fraglist+48/74>
20: e0820074 sc v0,116(a0)
Kernel panic: Aiee, killing interrupt handler!
1 warning issued. Results may not be reliable.
^ permalink raw reply
* Re: Locking model for NAPI drivers
From: Herbert Xu @ 2005-06-01 8:42 UTC (permalink / raw)
To: Andi Kleen; +Cc: davem, netdev
In-Reply-To: <m1fyw2wpzf.fsf@muc.de>
Andi Kleen <ak@muc.de> wrote:
>
> That is because of the kmap_atomic it does right? At least in the i386
> highmem implementation I don't see any code that would be less safe in
> hard interrupt context compared to BHs. And FRV and mips look like they
> allow it too.
To make it safe we'll have to allocate another precious km_type entry.
--
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
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