* Re: bcm43xx: "transmit timed out" and apparent hang with "preemptible periodic work" patches
From: Michael Buesch @ 2006-06-29 15:49 UTC (permalink / raw)
To: Paul Collins; +Cc: bcm43xx-dev, netdev, linville
In-Reply-To: <87mzbwvv07.fsf@briny.internal.ondioline.org>
On Thursday 29 June 2006 17:31, Paul Collins wrote:
> Michael Buesch <mb@bu3sch.de> writes:
>
> > On Thursday 29 June 2006 10:24, Paul Collins wrote:
> >> Michael Buesch <mb@bu3sch.de> writes:
> >>
> >> > On Monday 26 June 2006 14:43, Michael Buesch wrote:
> >> >> Try to get more logs.
> >> >> I suggest to do a netconsole for logging.
> >> >
> >> > Also note that current softmac trees have a patch missing.
> >> > It seems it got lost somewhere after my merge request.
> >> > I already contacted John in private for this, but no reply, yet.
> >> > The patch is attached. Maybe it fixes your issue.
> >>
> >> On a preempt kernel I can trigger the hang easily,
> >
> > How? I need to reproduce it to get a clue and fix it. :)
>
> I did it by running the commands I listed in my previous message.
> Here they are again, minus the pesky log messages.
>
> ip set link eth1 up
> ip set link eth1 down
> iwconfig eth1 essid wlan-ap enc off
> ip set link eth1 down
> ip set link eth1 up
> iwconfig eth1 essid wlan-ap enc off
> dhclient eth1
Uh, oh. You are doing an up-down-up cycle here...
I might get a clue now. This reminds me of some thought at yesterday
evening. I think that the up-down-up(down-up....) cycle is
broken and works only by accident mostly.
This bug might be hitting you here.
I will do a careful patch and send it out, later.
--
Greetings Michael.
^ permalink raw reply
* Re: bcm43xx: "transmit timed out" and apparent hang with "preemptible periodic work" patches
From: Larry Finger @ 2006-06-29 16:16 UTC (permalink / raw)
To: Michael Buesch
Cc: bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w, netdev-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <200606291731.50598.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
Michael Buesch wrote:
> On Thursday 29 June 2006 17:22, Larry Finger wrote:
>> Jun 29 01:22:08 larrylap kernel: bcm43xx: Controller restarted
>> Jun 29 01:23:08 larrylap kernel: bcm43xx: ASSERTION FAILED (channel >= 1 && channel <= 14) at:
>> drivers/net/wireless/bcm43xx/bcm43xx_radio.c:79:channel2freq_bg()
>
> WTF is that???
> How is that possible to happen?
> Are you sure you have an unmodified tree?
No, the tree is modified. It appears that something has messed up the bcm->ieee data. I am currently
in the process of re basing my copy of Linville's tree and will try with an unmodified version.
Larry
^ permalink raw reply
* [PATCH] ixgb: add PCI Error recovery callbacks
From: Linas Vepstas @ 2006-06-29 16:26 UTC (permalink / raw)
To: Jesse Brandeburg, Ronciak, John, bibo,mao, Rajesh Shah
Cc: Grant Grundler, akpm, linux-kernel, linux-pci, netdev
Adds PCI Error recovery callbacks to the Intel 10-gigabit ethernet
ixgb device driver. Lightly tested, works.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/net/ixgb/ixgb_main.c | 112 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 111 insertions(+), 1 deletion(-)
Index: linux-2.6.17-mm3/drivers/net/ixgb/ixgb_main.c
===================================================================
--- linux-2.6.17-mm3.orig/drivers/net/ixgb/ixgb_main.c 2006-06-27 11:39:08.000000000 -0500
+++ linux-2.6.17-mm3/drivers/net/ixgb/ixgb_main.c 2006-06-28 18:04:32.000000000 -0500
@@ -118,15 +118,26 @@ static void ixgb_restore_vlan(struct ixg
static void ixgb_netpoll(struct net_device *dev);
#endif
-/* Exported from other modules */
+static pci_ers_result_t ixgb_io_error_detected (struct pci_dev *pdev,
+ enum pci_channel_state state);
+static pci_ers_result_t ixgb_io_slot_reset (struct pci_dev *pdev);
+static void ixgb_io_resume (struct pci_dev *pdev);
+/* Exported from other modules */
extern void ixgb_check_options(struct ixgb_adapter *adapter);
+static struct pci_error_handlers ixgb_err_handler = {
+ .error_detected = ixgb_io_error_detected,
+ .slot_reset = ixgb_io_slot_reset,
+ .resume = ixgb_io_resume,
+};
+
static struct pci_driver ixgb_driver = {
.name = ixgb_driver_name,
.id_table = ixgb_pci_tbl,
.probe = ixgb_probe,
.remove = __devexit_p(ixgb_remove),
+ .err_handler = &ixgb_err_handler
};
MODULE_AUTHOR("Intel Corporation, <linux.nics@intel.com>");
@@ -1543,6 +1554,11 @@ void
ixgb_update_stats(struct ixgb_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
+ struct pci_dev *pdev = adapter->pdev;
+
+ /* Prevent stats update while adapter is being reset */
+ if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
+ return;
if((netdev->flags & IFF_PROMISC) || (netdev->flags & IFF_ALLMULTI) ||
(netdev->mc_count > IXGB_MAX_NUM_MULTICAST_ADDRESSES)) {
@@ -2198,4 +2214,98 @@ static void ixgb_netpoll(struct net_devi
}
#endif
+/**
+ * ixgb_io_error_detected() - called when PCI error is detected
+ * @pdev pointer to pci device with error
+ * @state pci channel state after error
+ *
+ * This callback is called by the PCI subsystem whenever
+ * a PCI bus error is detected.
+ */
+static pci_ers_result_t ixgb_io_error_detected (struct pci_dev *pdev,
+ enum pci_channel_state state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct ixgb_adapter *adapter = netdev->priv;
+
+ if(netif_running(netdev))
+ ixgb_down(adapter, TRUE);
+
+ pci_disable_device(pdev);
+
+ /* Request a slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * ixgb_io_slot_reset - called after the pci bus has been reset.
+ * @pdev pointer to pci device with error
+ *
+ * This callback is called after the PCI buss has been reset.
+ * Basically, this tries to restart the card from scratch.
+ * This is a shortened version of the device probe/discovery code,
+ * it resembles the first-half of the ixgb_probe() routine.
+ */
+static pci_ers_result_t ixgb_io_slot_reset (struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct ixgb_adapter *adapter = netdev->priv;
+
+ if(pci_enable_device(pdev)) {
+ DPRINTK(PROBE, ERR, "Cannot re-enable PCI device after reset.\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ /* Perform card reset only on one instance of the card */
+ if (0 != PCI_FUNC (pdev->devfn))
+ return PCI_ERS_RESULT_RECOVERED;
+
+ pci_set_master(pdev);
+
+ netif_carrier_off(netdev);
+ netif_stop_queue(netdev);
+ ixgb_reset(adapter);
+
+ /* Make sure the EEPROM is good */
+ if(!ixgb_validate_eeprom_checksum(&adapter->hw)) {
+ DPRINTK(PROBE, ERR, "After reset, the EEPROM checksum is not valid.\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ ixgb_get_ee_mac_addr(&adapter->hw, netdev->dev_addr);
+ memcpy(netdev->perm_addr, netdev->dev_addr, netdev->addr_len);
+
+ if(!is_valid_ether_addr(netdev->perm_addr)) {
+ DPRINTK(PROBE, ERR, "After reset, invalid MAC address.\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * ixgb_io_resume - called when its OK to resume normal operations
+ * @pdev pointer to pci device with error
+ *
+ * The error recovery driver tells us that its OK to resume
+ * normal operation. Implementation resembles the second-half
+ * of the ixgb_probe() routine.
+ */
+static void ixgb_io_resume (struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct ixgb_adapter *adapter = netdev->priv;
+
+ pci_set_master(pdev);
+
+ if(netif_running(netdev)) {
+ if(ixgb_up(adapter)) {
+ printk ("ixgb: can't bring device back up after reset\n");
+ return;
+ }
+ }
+
+ netif_device_attach(netdev);
+ mod_timer(&adapter->watchdog_timer, jiffies);
+}
+
/* ixgb_main.c */
^ permalink raw reply
* Re: bcm43xx: "transmit timed out" and apparent hang with "preemptible periodic work" patches
From: Martin Langer @ 2006-06-29 16:47 UTC (permalink / raw)
To: Michael Buesch; +Cc: Larry Finger, Paul Collins, bcm43xx-dev, netdev, linville
In-Reply-To: <200606291731.50598.mb@bu3sch.de>
On Thu, Jun 29, 2006 at 05:31:50PM +0200, Michael Buesch wrote:
> On Thursday 29 June 2006 17:22, Larry Finger wrote:
> > Michael Buesch wrote:
> > > On Thursday 29 June 2006 10:24, Paul Collins wrote:
> > >> Michael Buesch <mb@bu3sch.de> writes:
> > >>> On Monday 26 June 2006 14:43, Michael Buesch wrote:
> > >>>> Try to get more logs.
> > >>>> I suggest to do a netconsole for logging.
> > >>> Also note that current softmac trees have a patch missing.
> > >>> It seems it got lost somewhere after my merge request.
> > >>> I already contacted John in private for this, but no reply, yet.
> > >>> The patch is attached. Maybe it fixes your issue.
> > >> On a preempt kernel I can trigger the hang easily,
> > >
> > > How? I need to reproduce it to get a clue and fix it. :)
> > > I have no idea where it might come from (I don't even know
> > > what exactly happens).
> > >
> > > And please provide a _full_ dmesg log without comments inbetween
> > > after triggering the hang (with a full Controller Restart cycle).
> > >
> >
> > I am having what I think is a similar problem, although my system does not hang. I cannot send dmesg
> > output as the buffer is quickly filled with the channel assertion messages you see below, but here
> > is the relevant section of /var/log/messages.
> >
> > Jun 29 01:22:08 larrylap kernel: NETDEV WATCHDOG: wlan0: transmit timed out
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Controller RESET (TX timeout) ...
> > Jun 29 01:22:08 larrylap kernel: ACPI: PCI interrupt for device 0000:02:00.0 disabled
> > Jun 29 01:22:08 larrylap kernel: PCI: Enabling device 0000:02:00.0 (0000 -> 0002)
> > Jun 29 01:22:08 larrylap kernel: ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 11
> > (level, low) -> IRQ 11
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Chip ID 0x4306, rev 0x2
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Number of cores: 6
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Ignoring additional 802.11 core.
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: PHY connected
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Radio turned off
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Radio turned off
> > Jun 29 01:22:08 larrylap kernel: bcm43xx: Controller restarted
> > Jun 29 01:23:08 larrylap kernel: bcm43xx: ASSERTION FAILED (channel >= 1 && channel <= 14) at:
> > drivers/net/wireless/bcm43xx/bcm43xx_radio.c:79:channel2freq_bg()
>
> WTF is that???
> How is that possible to happen?
This can also be a bug in the hardware, firmware or maybe in the mips
driver code. Running the original closed source linux mips driver I got
this funny result during normal operation
Channel: 2147439075
Signal: 718984492 dBm
Noise: 2147439075 dBm
It was about three days ago and I can't reproduce it.
But I do not care much about my closed source problems...
Martin
^ permalink raw reply
* Re: bcm43xx: "transmit timed out" and apparent hang with "preemptible periodic work" patches
From: Michael Buesch @ 2006-06-29 16:47 UTC (permalink / raw)
To: Martin Langer; +Cc: Larry Finger, Paul Collins, bcm43xx-dev, netdev, linville
In-Reply-To: <20060629164716.GA4548@tuba>
On Thursday 29 June 2006 18:47, Martin Langer wrote:
> On Thu, Jun 29, 2006 at 05:31:50PM +0200, Michael Buesch wrote:
> > On Thursday 29 June 2006 17:22, Larry Finger wrote:
> > > Michael Buesch wrote:
> > > > On Thursday 29 June 2006 10:24, Paul Collins wrote:
> > > >> Michael Buesch <mb@bu3sch.de> writes:
> > > >>> On Monday 26 June 2006 14:43, Michael Buesch wrote:
> > > >>>> Try to get more logs.
> > > >>>> I suggest to do a netconsole for logging.
> > > >>> Also note that current softmac trees have a patch missing.
> > > >>> It seems it got lost somewhere after my merge request.
> > > >>> I already contacted John in private for this, but no reply, yet.
> > > >>> The patch is attached. Maybe it fixes your issue.
> > > >> On a preempt kernel I can trigger the hang easily,
> > > >
> > > > How? I need to reproduce it to get a clue and fix it. :)
> > > > I have no idea where it might come from (I don't even know
> > > > what exactly happens).
> > > >
> > > > And please provide a _full_ dmesg log without comments inbetween
> > > > after triggering the hang (with a full Controller Restart cycle).
> > > >
> > >
> > > I am having what I think is a similar problem, although my system does not hang. I cannot send dmesg
> > > output as the buffer is quickly filled with the channel assertion messages you see below, but here
> > > is the relevant section of /var/log/messages.
> > >
> > > Jun 29 01:22:08 larrylap kernel: NETDEV WATCHDOG: wlan0: transmit timed out
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Controller RESET (TX timeout) ...
> > > Jun 29 01:22:08 larrylap kernel: ACPI: PCI interrupt for device 0000:02:00.0 disabled
> > > Jun 29 01:22:08 larrylap kernel: PCI: Enabling device 0000:02:00.0 (0000 -> 0002)
> > > Jun 29 01:22:08 larrylap kernel: ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 11
> > > (level, low) -> IRQ 11
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Chip ID 0x4306, rev 0x2
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Number of cores: 6
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Ignoring additional 802.11 core.
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: PHY connected
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Radio turned off
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Radio turned off
> > > Jun 29 01:22:08 larrylap kernel: bcm43xx: Controller restarted
> > > Jun 29 01:23:08 larrylap kernel: bcm43xx: ASSERTION FAILED (channel >= 1 && channel <= 14) at:
> > > drivers/net/wireless/bcm43xx/bcm43xx_radio.c:79:channel2freq_bg()
> >
> > WTF is that???
> > How is that possible to happen?
>
> This can also be a bug in the hardware, firmware
Ehm, how? The channel value is completely in software and never read
back from hardware.
> or maybe in the mips
> driver code. Running the original closed source linux mips driver I got
> this funny result during normal operation
>
> Channel: 2147439075
> Signal: 718984492 dBm
> Noise: 2147439075 dBm
A bug which we implemented, too, because we did not see it?
Well, possible. Although I don't find it :).
--
Greetings Michael.
^ permalink raw reply
* Re: RDMA will be reverted
From: Roland Dreier @ 2006-06-29 16:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, akpm
In-Reply-To: <20060628.000715.95062023.davem@davemloft.net>
David> Roland, there is no way in the world we would have let
David> support for RDMA into the kernel tree had we seen and
David> reviewed it on netdev. I've discussed this with Andrew
David> Morton, and we'd like you to please revert all of the RDMA
David> code from Linus's tree immedialtely.
David> Folks are well aware how against RDMA and TOE type schemes
David> the Linux networking developers are. So the fact that none
David> of these RDMA changes went up for review on netdev strikes
David> me as just a little bit more than suspicious.
[I'm really on paternity leave, but this was brought to my attention
and seems important enough to respond to]
Dave, you're going to have to be more specific. What do you mean by
RDMA? The whole drivers/infiniband infrastructure, which handles RDMA
over IB, has been upstream for a year and a half, and was in fact
originally merged by you, so I'm guessing that's not what you mean.
If you're talking about the "RDMA CM" (drivers/infiniband/core/cma.c
et al) that was just merged, then you should be aware that that was
posted by Sean Hefty to netdev for review, multiple times (eg a quick
search finds <http://lwn.net/Articles/170202/>). It is true that the
intention of the abstraction is to provide a common mechanism for
handling IB and iWARP (RDMA/TCP) connections, but at the moment no
iWARP code is upstream. Right now all it does is allow IP addressing
to be used for IB connections.
In any case I think we need to find a way for Linux to support iWARP
hardware, since there are users that want this, and (some of) the
vendors are working hard to do things the right way (including cc'ing
netdev on the conversation). I don't think it's good for Linux for
the answer to just be, "sorry, you're wrong to want to use that hardware."
- Roland
^ permalink raw reply
* RE: PATCH SB1250 NAPI support
From: Mark E Mason @ 2006-06-29 17:15 UTC (permalink / raw)
To: Martin Michlmayr, jgarzik, netdev; +Cc: Tom Rix, Mark E Mason
Hello,
We've done some further work on the bcm1250/bcm1480 MAC driver since
then, primarily in the area of performance improvements, but we've not
quite ready to submit the patch for those changes yet.
In the meantime, Tom's patch fixes all of the really bad problems, and
we'd really appreciate it if it could be merged in.
Thx,
Mark Mason
Broadcom
> -----Original Message-----
> From: Martin Michlmayr [mailto:tbm@cyrius.com]
> Sent: Thursday, June 29, 2006 1:22 AM
> To: jgarzik@pobox.com; netdev@vger.kernel.org
> Cc: Tom Rix; Mark E Mason
> Subject: Re: PATCH SB1250 NAPI support
>
> * Tom Rix <trix@specifix.com> [2006-06-04 11:45]:
> > A while ago I submitted this patch for NAPI support for
> SB1250 / SB1480.
> > I have tested it again on the recent (6/3/06) linux-mips kernel.
>
> Are there any comments regarding this patch (apart from the fact that
> Tom forgot to include a Signed-off-by line). Can it go in when it's
> resent with a Signed-off-by line or does the patch have any other
> problems?
> --
> Martin Michlmayr
> tbm@cyrius.com
>
>
^ permalink raw reply
* Re: Netchannels: progress report.
From: James Morris @ 2006-06-29 17:19 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David S. Miller, netdev
In-Reply-To: <20060629093801.GA6049@2ka.mipt.ru>
On Thu, 29 Jun 2006, Evgeniy Polyakov wrote:
> +#define __NR_netchannel_control 279
> +__SYSCALL(__NR_vmsplice, sys_netchannel_control)
This looks wrong.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: RDMA will be reverted
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-06-29 17:32 UTC (permalink / raw)
To: rdreier; +Cc: davem, netdev, akpm, yoshfuji
In-Reply-To: <adawtazgawi.fsf@cisco.com>
Hello.
In article <adawtazgawi.fsf@cisco.com> (at Thu, 29 Jun 2006 09:54:37 -0700), Roland Dreier <rdreier@cisco.com> says:
> David> Roland, there is no way in the world we would have let
> David> support for RDMA into the kernel tree had we seen and
> David> reviewed it on netdev. I've discussed this with Andrew
> David> Morton, and we'd like you to please revert all of the RDMA
> David> code from Linus's tree immedialtely.
>
> David> Folks are well aware how against RDMA and TOE type schemes
> David> the Linux networking developers are. So the fact that none
> David> of these RDMA changes went up for review on netdev strikes
> David> me as just a little bit more than suspicious.
>
> [I'm really on paternity leave, but this was brought to my attention
> and seems important enough to respond to]
>
> Dave, you're going to have to be more specific. What do you mean by
> RDMA? The whole drivers/infiniband infrastructure, which handles RDMA
> over IB, has been upstream for a year and a half, and was in fact
> originally merged by you, so I'm guessing that's not what you mean.
NET_DMA things.
--yoshfuji
^ permalink raw reply
* Re: RDMA will be reverted
From: Roland Dreier @ 2006-06-29 17:35 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=
Cc: davem, netdev, akpm
In-Reply-To: <20060630.023258.83835473.yoshfuji@linux-ipv6.org>
> > Dave, you're going to have to be more specific. What do you mean by
> > RDMA? The whole drivers/infiniband infrastructure, which handles RDMA
> > over IB, has been upstream for a year and a half, and was in fact
> > originally merged by you, so I'm guessing that's not what you mean.
>
> NET_DMA things.
But NET_DMA seems to be for the new DMA engine support (I/OAT really I
guess?). I had nothing to do with merging any of that, and as far as
I can tell, Dave signed off on all of those changes, so I don't think
that's what he's complaining about either.
- R.
^ permalink raw reply
* Re: RDMA will be reverted
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-06-29 17:40 UTC (permalink / raw)
To: rdreier; +Cc: davem, netdev, akpm, yoshfuji
In-Reply-To: <adasllng8zn.fsf@cisco.com>
In article <adasllng8zn.fsf@cisco.com> (at Thu, 29 Jun 2006 10:35:56 -0700), Roland Dreier <rdreier@cisco.com> says:
> > > Dave, you're going to have to be more specific. What do you mean by
> > > RDMA? The whole drivers/infiniband infrastructure, which handles RDMA
> > > over IB, has been upstream for a year and a half, and was in fact
> > > originally merged by you, so I'm guessing that's not what you mean.
> >
> > NET_DMA things.
>
> But NET_DMA seems to be for the new DMA engine support (I/OAT really I
> guess?). I had nothing to do with merging any of that, and as far as
> I can tell, Dave signed off on all of those changes, so I don't think
> that's what he's complaining about either.
Oops, sorry, you're right...
--yoshfuji
^ permalink raw reply
* Re: Netchannels: progress report.
From: Evgeniy Polyakov @ 2006-06-29 18:15 UTC (permalink / raw)
To: James Morris; +Cc: David S. Miller, netdev
In-Reply-To: <Pine.LNX.4.64.0606291318420.24645@d.namei>
On Thu, Jun 29, 2006 at 01:19:29PM -0400, James Morris (jmorris@namei.org) wrote:
> On Thu, 29 Jun 2006, Evgeniy Polyakov wrote:
>
> > +#define __NR_netchannel_control 279
> > +__SYSCALL(__NR_vmsplice, sys_netchannel_control)
>
> This looks wrong.
Ugh, it's my hand merge for x86_64.
Thank you for spotting this, James.
> --
> James Morris
> <jmorris@namei.org>
--
Evgeniy Polyakov
^ permalink raw reply
* jumbo frames and memory fragmentation
From: Chris Friesen @ 2006-06-29 18:54 UTC (permalink / raw)
To: netdev
I'm running a system with multiple e1000 devices, using 9KB jumbo
frames. I'm running a modified 2.6.10 with e1000 driver 5.5.4-k2.
I'm a bit concerned about the behaviour of this driver with jumbo
frames. We ask for 9KB. The driver then bumps that up to a
power-of-two, so it calls dev_alloc_skb(16384). That then bumps it up a
bit to allow for its own overhead, so it appears that we end up asking
for 32KB of physically contiguous memory for every packet coming in. Ouch.
Add to that the fact that this version of the driver doesn't do
copybreak, and it means that after we're up for a few days it starts
complaining about not being able to allocate buffers.
Anyone have any suggestions on how to improve this? Upgrading kernels
isn't an option. I could port back the copybreak stuff fairly easily.
Back in 2.4 some of the drivers used to retry buffer allocations using
GFP_KERNEL once interrupts were reenabled. I don't see many of them
doing that anymore--would there be any benefit to that?
Thanks,
Chris
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Shailabh Nagar @ 2006-06-29 19:10 UTC (permalink / raw)
To: Andrew Morton
Cc: Paul Jackson, Valdis.Kletnieks, jlan, balbir, csturtiv,
linux-kernel, Jamal, netdev
In-Reply-To: <20060629110107.2e56310b.akpm@osdl.org>
Andrew Morton wrote:
>On Thu, 29 Jun 2006 09:44:08 -0700
>Paul Jackson <pj@sgi.com> wrote:
>
>
>
>>>You're probably correct on that model. However, it all depends on the actual
>>>workload. Are people who actually have large-CPU (>256) systems actually
>>>running fork()-heavy things like webservers on them, or are they running things
>>>like database servers and computations, which tend to have persistent
>>>processes?
>>>
>>>
>>It may well be mostly as you say - the large-CPU systems not running
>>the fork() heavy jobs.
>>
>>Sooner or later, someone will want to run a fork()-heavy job on a
>>large-CPU system. On a 1024 CPU system, it would apparently take
>>just 14 exits/sec/CPU to hit this bottleneck, if Jay's number of
>>14000 applied.
>>
>>Chris Sturdivant's reply is reasonable -- we'll hit it sooner or later,
>>and deal with it then.
>>
>>
>>
>
>I agree, and I'm viewing this as blocking the taskstats merge. Because if
>this _is_ a problem then it's a big one because fixing it will be
>intrusive, and might well involve userspace-visible changes.
>
>
First off, just a reminder that this is inherently a netlink flow
control issue...which was being exacerbated
earlier by taskstats decision to send per-tgid data (no longer the case).
But I'd like to know whats our target here ? How many messages per
second do we want to be able to be sent
and received without risking any loss of data ? Netlink will lose
messages at a high enough rate so the design point
will need to be known a bit.
For statistics type usage of the genetlink/netlink, I would have thought
that userspace, provided it is reliably informed
about the loss of data through ENOBUFS, could take measures to just
account for the missing data and carry on ?
>The only ways I can see of fixing the problem generally are to either
>
>a) throw more CPU(s) at stats collection: allow userspace to register for
> "stats generated by CPU N", then run a stats collection daemon on each
> CPU or
>
>
>b) make the kernel recognise when it's getting overloaded and switch to
> some degraded mode where it stops trying to send all the data to
> userspace - just send a summary, or a "we goofed" message or something.
>
>
One of the unused features of genetlink that's meant for high volume
data output from the kernel is
the "dump" callback of a genetlink connection. Essentially kernel space
keeps getting provided sk_buffs
to fill which the netlink layer then supplies to user space (over time I
guess ?)
But whatever we do, there's going to be some limit so its useful to
decide what the design point should be ?
Adding Jamal for his thoughts on netlink's flow control in the context
of genetlink.
--Shailabh
^ permalink raw reply
* [2.6 patch] make net/core/skbuff.c:skb_release_data() static
From: Adrian Bunk @ 2006-06-29 19:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20060623.040115.108744369.davem@davemloft.net>
On Fri, Jun 23, 2006 at 04:01:15AM -0700, David Miller wrote:
> From: Adrian Bunk <bunk@stusta.de>
> Date: Fri, 23 Jun 2006 12:56:23 +0200
>
> > skb_release_data() no longer has any users in other files.
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> If you are going to do this, you need to remove the reference
> in arch/x86_64/kernel/functionlist too.
>
> Thanks.
Corrected patch below.
cu
Adrian
<-- snip -->
skb_release_data() no longer has any users in other files.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
arch/x86_64/kernel/functionlist | 1 -
include/linux/skbuff.h | 1 -
net/core/skbuff.c | 2 +-
3 files changed, 1 insertion(+), 3 deletions(-)
--- linux-2.6.17-mm4-full/include/linux/skbuff.h.old 2006-06-29 15:19:52.000000000 +0200
+++ linux-2.6.17-mm4-full/include/linux/skbuff.h 2006-06-29 15:19:59.000000000 +0200
@@ -1301,7 +1301,6 @@
extern void skb_split(struct sk_buff *skb,
struct sk_buff *skb1, const u32 len);
-extern void skb_release_data(struct sk_buff *skb);
extern struct sk_buff *skb_segment(struct sk_buff *skb, int sg);
static inline void *skb_header_pointer(const struct sk_buff *skb, int offset,
--- linux-2.6.17-mm4-full/net/core/skbuff.c.old 2006-06-29 15:20:10.000000000 +0200
+++ linux-2.6.17-mm4-full/net/core/skbuff.c 2006-06-29 15:20:17.000000000 +0200
@@ -279,7 +279,7 @@
skb_get(list);
}
-void skb_release_data(struct sk_buff *skb)
+static void skb_release_data(struct sk_buff *skb)
{
if (!skb->cloned ||
!atomic_sub_return(skb->nohdr ? (1 << SKB_DATAREF_SHIFT) + 1 : 1,
--- linux-2.6.17-mm4-full/arch/x86_64/kernel/functionlist.old 2006-06-29 15:20:26.000000000 +0200
+++ linux-2.6.17-mm4-full/arch/x86_64/kernel/functionlist 2006-06-29 15:20:30.000000000 +0200
@@ -384,7 +384,6 @@
*(.text.__end_that_request_first)
*(.text.wake_up_bit)
*(.text.unuse_mm)
-*(.text.skb_release_data)
*(.text.shrink_icache_memory)
*(.text.sched_balance_self)
*(.text.__pmd_alloc)
^ permalink raw reply
* [2.6 patch] net/xfrm/xfrm_state: unexport xfrm_state_mtu
From: Adrian Bunk @ 2006-06-29 19:20 UTC (permalink / raw)
To: netdev
This patch removes the unused EXPORT_SYMBOL(xfrm_state_mtu).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 12 Apr 2006
--- linux-2.6.17-rc1-mm2-full/net/xfrm/xfrm_state.c.old 2006-04-12 22:38:57.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/net/xfrm/xfrm_state.c 2006-04-12 22:39:03.000000000 +0200
@@ -1152,8 +1152,6 @@
return res;
}
-EXPORT_SYMBOL(xfrm_state_mtu);
-
int xfrm_init_state(struct xfrm_state *x)
{
struct xfrm_state_afinfo *afinfo;
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Paul Jackson @ 2006-06-29 19:23 UTC (permalink / raw)
To: Shailabh Nagar
Cc: akpm, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel,
hadi, netdev
In-Reply-To: <44A425A7.2060900@watson.ibm.com>
Shailabh wrote:
> First off, just a reminder that this is inherently a netlink flow
> control issue...which was being exacerbated earlier by taskstats
> decision to send per-tgid data (no longer the case).
>
> But I'd like to know whats our target here ? How many messages
> per second do we want to be able to be sent and received without
> risking any loss of data ? Netlink will lose messages at a high
> enough rate so the design point will need to be known a bit.
Perhaps its not so much an issue of the design rate, as an issue of
how we deal with hitting the limit. Sooner or later, perhaps due to
operator error, almost any implementable rate will be exceeded.
Ideally, we would both of the remedies that Andrew mentioned,
rephrasing:
1) a way for a customer who needs a higher rate to scale
the useful resources he can apply to the collection, and
2) a clear indicator when the supported rate was exceeded
anyway.
> For statistics type usage of the genetlink/netlink, I would have
> thought that userspace, provided it is reliably informed about the loss
> of data through ENOBUFS, could take measures to just account for the
> missing data and carry on ?
If that's so, then the ENOBUFS error may well meet my remedy (2) above,
leaving just the question of how a customer could scale to higher
rates, if they found it was worth doing so.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* Re: 2.6.17-mm3 -- BUG: illegal lock usage -- illegal {softirq-on-W} -> {in-softirq-R} usage.
From: Andrew Morton @ 2006-06-29 19:26 UTC (permalink / raw)
To: Miles Lane; +Cc: linux-kernel, netdev
In-Reply-To: <a44ae5cd0606291201v659b4235sfa9941aa3b18e766@mail.gmail.com>
On Thu, 29 Jun 2006 12:01:06 -0700
"Miles Lane" <miles.lane@gmail.com> wrote:
> [ BUG: illegal lock usage! ]
> ----------------------------
This is claiming that we're taking sk->sk_dst_lock in a deadlockable manner.
> illegal {softirq-on-W} -> {in-softirq-R} usage.
It found someone doing write_lock(sk_dst_lock) with softirqs enabled, but
someone else takes read_lock(dst_lock) inside softirqs.
> java_vm/4418 [HC0[0]:SC1[1]:HE1:SE0] takes:
> (&sk->sk_dst_lock){---?}, at: [<c119d0a9>] sk_dst_check+0x1b/0xe6
> {softirq-on-W} state was registered at:
> [<c102d1c8>] lock_acquire+0x60/0x80
> [<c12012d7>] _write_lock+0x23/0x32
> [<c11ddbe7>] inet_bind+0x16c/0x1cc
> [<c119ae58>] sys_bind+0x61/0x80
> [<c119b465>] sys_socketcall+0x7d/0x186
> [<c1002d6d>] sysenter_past_esp+0x56/0x8d
inet_bind()
->sk_dst_get
->read_lock(&sk->sk_dst_lock)
> irq event stamp: 11052
> hardirqs last enabled at (11052): [<c105d454>] kmem_cache_alloc+0x89/0xa6
> hardirqs last disabled at (11051): [<c105d405>] kmem_cache_alloc+0x3a/0xa6
> softirqs last enabled at (11040): [<c11a506d>] dev_queue_xmit+0x224/0x24b
> softirqs last disabled at (11041): [<c1004a64>] do_softirq+0x58/0xbd
>
> other info that might help us debug this:
> 1 lock held by java_vm/4418:
> #0: (af_family_keys + (sk)->sk_family#4){-+..}, at: [<f93c9281>]
> tcp_v6_rcv+0x308/0x7b7 [ipv6]
softirq
->ip6_dst_lookup
->sk_dst_check
->sk_dst_reset
->write_lock(&sk->sk_dst_lock);
> stack backtrace:
> [<c1003502>] show_trace_log_lvl+0x54/0xfd
> [<c1003b6a>] show_trace+0xd/0x10
> [<c1003c0e>] dump_stack+0x19/0x1b
> [<c102b833>] print_usage_bug+0x1cc/0x1d9
> [<c102bd34>] mark_lock+0x193/0x360
> [<c102c94a>] __lock_acquire+0x3b7/0x970
> [<c102d1c8>] lock_acquire+0x60/0x80
> [<c12013eb>] _read_lock+0x23/0x32
> [<c119d0a9>] sk_dst_check+0x1b/0xe6
> [<f93ae479>] ip6_dst_lookup+0x31/0x172 [ipv6]
> [<f93c7065>] tcp_v6_send_synack+0x10f/0x238 [ipv6]
> [<f93c7dc5>] tcp_v6_conn_request+0x281/0x2c7 [ipv6]
> [<c11cca33>] tcp_rcv_state_process+0x5d/0xbde
> [<f93c7414>] tcp_v6_do_rcv+0x26d/0x384 [ipv6]
> [<f93c96d6>] tcp_v6_rcv+0x75d/0x7b7 [ipv6]
> [<f93afadd>] ip6_input+0x201/0x2d1 [ipv6]
> [<f93b002d>] ipv6_rcv+0x190/0x1bf [ipv6]
> [<c11a3200>] netif_receive_skb+0x2e6/0x37f
> [<c11a4b81>] process_backlog+0x80/0x112
> [<c11a4c9e>] net_rx_action+0x8b/0x1e8
> [<c101a711>] __do_softirq+0x55/0xb0
> [<c1004a64>] do_softirq+0x58/0xbd
> [<c101a978>] local_bh_enable+0xd0/0x107
> [<c11a506d>] dev_queue_xmit+0x224/0x24b
> [<c11a9bb8>] neigh_resolve_output+0x1e2/0x20e
> [<f93add64>] ip6_output2+0x1de/0x1fc [ipv6]
> [<f93ae41e>] ip6_output+0x69c/0x6c6 [ipv6]
> [<f93aeb58>] ip6_xmit+0x22b/0x295 [ipv6]
> [<f93cc893>] inet6_csk_xmit+0x200/0x20e [ipv6]
> [<c11cea04>] tcp_transmit_skb+0x5de/0x60c
> [<c11d0cd7>] tcp_connect+0x2bb/0x31a
> [<f93c894a>] tcp_v6_connect+0x520/0x655 [ipv6]
> [<c11dd889>] inet_stream_connect+0x83/0x20f
> [<c119adda>] sys_connect+0x67/0x84
> [<c119b474>] sys_socketcall+0x8c/0x186
> [<c1002d6d>] sysenter_past_esp+0x56/0x8d
So the allegation is that if a softirq runs sk_dst_reset() while
process-context code is running sk_dst_set(), we'll do write_lock() while
holding read_lock().
^ permalink raw reply
* Re: [NET]: Added GSO header verification
From: David Miller @ 2006-06-29 19:26 UTC (permalink / raw)
To: mchan; +Cc: herbert, netdev
In-Reply-To: <1151460444.5124.2.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 27 Jun 2006 19:07:24 -0700
> On Wed, 2006-06-28 at 08:31 +1000, Herbert Xu wrote:
>
> > [NET]: Fix logical error in skb_gso_ok
> >
> > The test in skb_gso_ok is backwards. Noticed by Michael Chan
> > <mchan@broadcom.com>.
> >
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Acked-by: Michael Chan <mchan@broadcom.com>
Applied, thanks a lot guys.
^ permalink raw reply
* Re: [Patch 1/1] AF_UNIX Datagram getpeersec (minor fix)
From: David Miller @ 2006-06-29 19:28 UTC (permalink / raw)
To: jmorris
Cc: cxzhang, netdev, jmorris, chrisw, herbert, sds, tjaeger, akpm,
latten, sergeh, gcwilson, czhang.us
In-Reply-To: <Pine.LNX.4.64.0606281000150.12544@d.namei>
From: James Morris <jmorris@namei.org>
Date: Wed, 28 Jun 2006 10:00:48 -0400 (EDT)
> On Wed, 28 Jun 2006, Catherine Zhang wrote:
>
> > Hi,
> >
> > Minor fix (un-export selinux_get_sock_sid()).
>
> Thanks, looks ok to me.
>
> Acked-by: James Morris <jmorris@namei.org>
Applied, thanks a lot.
^ permalink raw reply
* Re: [Patch 1/1] AF_UNIX Datagram getpeersec (minor fix)
From: Xiaolan Zhang @ 2006-06-29 19:29 UTC (permalink / raw)
To: David Miller
Cc: akpm, chrisw, cxzhang, czhang.us, George Wilson, herbert, jmorris,
jmorris, latten, netdev, sds, Serge E Hallyn, tjaeger
In-Reply-To: <20060629.122800.108743929.davem@davemloft.net>
Thank you all for your help! It's been great working with you.
Catherine
David Miller <davem@davemloft.net> wrote on 06/29/2006 03:28:00 PM:
> From: James Morris <jmorris@namei.org>
> Date: Wed, 28 Jun 2006 10:00:48 -0400 (EDT)
>
> > On Wed, 28 Jun 2006, Catherine Zhang wrote:
> >
> > > Hi,
> > >
> > > Minor fix (un-export selinux_get_sock_sid()).
> >
> > Thanks, looks ok to me.
> >
> > Acked-by: James Morris <jmorris@namei.org>
>
> Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH]NET: Add ECN support for TSO
From: David Miller @ 2006-06-29 19:30 UTC (permalink / raw)
To: mchan; +Cc: herbert, netdev
In-Reply-To: <1151469421.3502.3.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 27 Jun 2006 21:37:01 -0700
> [NET]: Add ECN support for TSO
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH]bnx2: Add NETIF_F_TSO_ECN
From: David Miller @ 2006-06-29 19:31 UTC (permalink / raw)
To: mchan; +Cc: herbert, netdev
In-Reply-To: <1151464024.5124.14.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 27 Jun 2006 20:07:04 -0700
> Add NETIF_F_TSO_ECN feature for all bnx2 hardware.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH 1/3] [TIPC] Fixed skb_under_panic caused by tipc_link_bundle_buf
From: David Miller @ 2006-06-29 19:34 UTC (permalink / raw)
To: per.liden; +Cc: netdev, allan.stephens
In-Reply-To: <11514964722073-git-send-email-per.liden@ericsson.com>
From: Per Liden <per.liden@ericsson.com>
Date: Wed, 28 Jun 2006 14:07:50 +0200
> From: Allan Stephens <allan.stephens@windriver.com>
>
> Now determines tailroom of bundle buffer by directly inspection of buffer.
> Previously, buffer was assumed to have a max capacity equal to the link MTU,
> but the addition of link MTU negotiation means that the link MTU can increase
> after the bundle buffer is allocated.
>
> Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
> Signed-off-by: Per Liden <per.liden@ericsson.com>
Applied, thanks.
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Andrew Morton @ 2006-06-29 19:33 UTC (permalink / raw)
To: Shailabh Nagar
Cc: pj, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel, hadi,
netdev
In-Reply-To: <44A425A7.2060900@watson.ibm.com>
On Thu, 29 Jun 2006 15:10:31 -0400
Shailabh Nagar <nagar@watson.ibm.com> wrote:
> >I agree, and I'm viewing this as blocking the taskstats merge. Because if
> >this _is_ a problem then it's a big one because fixing it will be
> >intrusive, and might well involve userspace-visible changes.
> >
> >
> First off, just a reminder that this is inherently a netlink flow
> control issue...which was being exacerbated
> earlier by taskstats decision to send per-tgid data (no longer the case).
>
> But I'd like to know whats our target here ? How many messages per
> second do we want to be able to be sent
> and received without risking any loss of data ? Netlink will lose
> messages at a high enough rate so the design point
> will need to be known a bit.
>
> For statistics type usage of the genetlink/netlink, I would have thought
> that userspace, provided it is reliably informed
> about the loss of data through ENOBUFS, could take measures to just
> account for the missing data and carry on ?
Could be so. But we need to understand how significant the impact of this
will be in practice.
We could find, once this is deployed is real production environments on
large machines that the data loss is sufficiently common and sufficiently
serious that the feature needs a lot of rework.
Now there's always a risk of that sort of thing happening with all
features, but it's usually not this evident so early in the development
process. We need to get a better understanding of the risk before
proceeding too far.
And there's always a 100% reliable fix for this: throttling. Make the
sender of the messages block until the consumer can catch up. In some
situations, that is what people will want to be able to do. I suspect a
good implementation would be to run a collection daemon on each CPU and
make the delivery be cpu-local. That's sounding more like relayfs than
netlink.
^ 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