* Re: [PATCH 03/10] net/fec: add mac field into platform data and consolidate fec_get_mac
From: Shawn Guo @ 2010-12-29 12:00 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Baruch Siach, davem, gerg, eric, bryan.wu, r64343, B32542, lw,
w.sang, s.hauer, linux-arm-kernel, netdev
In-Reply-To: <20101229111019.GA14221@pengutronix.de>
Hi Uwe,
On Wed, Dec 29, 2010 at 12:10:19PM +0100, Uwe Kleine-König wrote:
> Hi Shawn,
>
> On Wed, Dec 29, 2010 at 07:08:29PM +0800, Shawn Guo wrote:
> > On Wed, Dec 29, 2010 at 11:37:58AM +0100, Uwe Kleine-König wrote:
> > > On Wed, Dec 29, 2010 at 06:30:15PM +0800, Shawn Guo wrote:
> > > > > On Tue, Dec 28, 2010 at 10:55:48PM +0800, Shawn Guo wrote:
> > > > [...]
> > > > > > + /*
> > > > > > + * try to get mac address in following order:
> > > > > > + *
> > > > > > + * 1) kernel command line fec_mac=xx:xx:xx...
> > > > > > + */
> > > > > > + iap = fec_mac_default;
> > > > > > +
> > > > > > + /*
> > > > > > + * 2) from flash or fuse (via platform data)
> > > > > > + */
> > > > >
> > > > > Again, how do you handle the dual MAC case?
> > > > >
> > > > For the platform data case, the following patch reads both mac
> > > > addresses.
> > > >
> > > > [PATCH 09/10] ARM: mx28: read fec mac address from ocotp
> > > >
> > > > +static int __init mx28evk_fec_get_mac(void)
> > > > +{
> > > > + int i, ret;
> > > > + u32 val;
> > > > +
> > > > + /*
> > > > + * OCOTP only stores the last 4 octets for each mac address,
> > > > + * so hard-coding the first two octets as Freescale OUI (00:04:9f)
> > > > + * is needed.
> > > > + */
> > > > + for (i = 0; i < 2; i++) {
> > > > + ret = mxs_read_ocotp(0x20 + i * 0x10, 1, &val);
> > > > + if (ret)
> > > > + goto error;
> > > > +
> > > > + mx28_fec_pdata[i].mac[0] = 0x00;
> > > > + mx28_fec_pdata[i].mac[1] = 0x04;
> > > > + mx28_fec_pdata[i].mac[2] = (val >> 24) & 0xff;
> > > > + mx28_fec_pdata[i].mac[3] = (val >> 16) & 0xff;
> > > > + mx28_fec_pdata[i].mac[4] = (val >> 8) & 0xff;
> > > > + mx28_fec_pdata[i].mac[5] = (val >> 0) & 0xff;
> > > uuh. Is ((val >> 24) & 0xff) supposed to be 0x9f? If not this might
> > > have unwanted effects (practical, don't know about legal ones).
> > Yes, it is 0x9f.
> Then maybe hardcode that, or at least warn if it's not?
>
Will hard-code it.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 03/10] net/fec: add mac field into platform data and consolidate fec_get_mac
From: Shawn Guo @ 2010-12-29 11:58 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Baruch Siach, davem, gerg, eric, bryan.wu, r64343, B32542, lw,
w.sang, s.hauer, linux-arm-kernel, netdev
In-Reply-To: <20101229103138.GT14221@pengutronix.de>
Hi Uwe,
On Wed, Dec 29, 2010 at 11:31:38AM +0100, Uwe Kleine-König wrote:
> Hello Shawn,
>
> On Wed, Dec 29, 2010 at 06:05:21PM +0800, Shawn Guo wrote:
> > On Wed, Dec 29, 2010 at 08:53:30AM +0200, Baruch Siach wrote:
> > > Hi Shawn,
> > > In the case of dual MAC that you later add support for, the address which one
> > > is being set? Is there a way to set both in kernel command line?
> > >
> > The fec0 gets fec_mac and fec1 gets fec_mac + 1. The following code
> > in function fec_get_mac takes care of it.
> >
> > /* Adjust MAC if using default MAC address */
> default MAC address means the address passed via cmdline? Sounds
> confusing to me.
Will change the comment and fec_mac_default name to address
the concern.
>
> > if (iap == fec_mac_default)
> > dev->dev_addr[ETH_ALEN-1] = fec_mac_default[ETH_ALEN-1] + fep->pdev->id;
> Can this overflow? (I didn't check the code, so my concern might be
> completely stupid here.)
No. dev->dev_addr points to netdev_hw_addr->addr, which is a 32 bytes array.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 03/10] net/fec: add mac field into platform data and consolidate fec_get_mac
From: Uwe Kleine-König @ 2010-12-29 11:10 UTC (permalink / raw)
To: Shawn Guo
Cc: Baruch Siach, davem, gerg, eric, bryan.wu, r64343, B32542, lw,
w.sang, s.hauer, linux-arm-kernel, netdev
In-Reply-To: <20101229110828.GE19347@freescale.com>
Hi Shawn,
On Wed, Dec 29, 2010 at 07:08:29PM +0800, Shawn Guo wrote:
> On Wed, Dec 29, 2010 at 11:37:58AM +0100, Uwe Kleine-König wrote:
> > On Wed, Dec 29, 2010 at 06:30:15PM +0800, Shawn Guo wrote:
> > > > On Tue, Dec 28, 2010 at 10:55:48PM +0800, Shawn Guo wrote:
> > > [...]
> > > > > + /*
> > > > > + * try to get mac address in following order:
> > > > > + *
> > > > > + * 1) kernel command line fec_mac=xx:xx:xx...
> > > > > + */
> > > > > + iap = fec_mac_default;
> > > > > +
> > > > > + /*
> > > > > + * 2) from flash or fuse (via platform data)
> > > > > + */
> > > >
> > > > Again, how do you handle the dual MAC case?
> > > >
> > > For the platform data case, the following patch reads both mac
> > > addresses.
> > >
> > > [PATCH 09/10] ARM: mx28: read fec mac address from ocotp
> > >
> > > +static int __init mx28evk_fec_get_mac(void)
> > > +{
> > > + int i, ret;
> > > + u32 val;
> > > +
> > > + /*
> > > + * OCOTP only stores the last 4 octets for each mac address,
> > > + * so hard-coding the first two octets as Freescale OUI (00:04:9f)
> > > + * is needed.
> > > + */
> > > + for (i = 0; i < 2; i++) {
> > > + ret = mxs_read_ocotp(0x20 + i * 0x10, 1, &val);
> > > + if (ret)
> > > + goto error;
> > > +
> > > + mx28_fec_pdata[i].mac[0] = 0x00;
> > > + mx28_fec_pdata[i].mac[1] = 0x04;
> > > + mx28_fec_pdata[i].mac[2] = (val >> 24) & 0xff;
> > > + mx28_fec_pdata[i].mac[3] = (val >> 16) & 0xff;
> > > + mx28_fec_pdata[i].mac[4] = (val >> 8) & 0xff;
> > > + mx28_fec_pdata[i].mac[5] = (val >> 0) & 0xff;
> > uuh. Is ((val >> 24) & 0xff) supposed to be 0x9f? If not this might
> > have unwanted effects (practical, don't know about legal ones).
> Yes, it is 0x9f.
Then maybe hardcode that, or at least warn if it's not?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 03/10] net/fec: add mac field into platform data and consolidate fec_get_mac
From: Shawn Guo @ 2010-12-29 11:08 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Baruch Siach, davem, gerg, eric, bryan.wu, r64343, B32542, lw,
w.sang, s.hauer, linux-arm-kernel, netdev
In-Reply-To: <20101229103758.GU14221@pengutronix.de>
Hi Uwe,
On Wed, Dec 29, 2010 at 11:37:58AM +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Wed, Dec 29, 2010 at 06:30:15PM +0800, Shawn Guo wrote:
> > Sorry, Baruch. I missed two comments in the last reply.
> >
> > On Wed, Dec 29, 2010 at 08:53:30AM +0200, Baruch Siach wrote:
> > > Hi Shawn,
> > >
> > > Please add netdev@vger.kernel.org to the Cc of all your fec driver patches.
> > >
> > I was aware of this after I sent out the patch set last night.
> > Can I just resend all the patches in v2 and get netdev@vger.kernel.org
> > included?
> [I just added netdev for this reply. I think adding it for v2 is OK
> then. For those interested, the whole series can be found at
>
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/100902
>
> .]
>
Thanks.
> > > On Tue, Dec 28, 2010 at 10:55:48PM +0800, Shawn Guo wrote:
> > [...]
> > > > + /*
> > > > + * try to get mac address in following order:
> > > > + *
> > > > + * 1) kernel command line fec_mac=xx:xx:xx...
> > > > + */
> > > > + iap = fec_mac_default;
> > > > +
> > > > + /*
> > > > + * 2) from flash or fuse (via platform data)
> > > > + */
> > >
> > > Again, how do you handle the dual MAC case?
> > >
> > For the platform data case, the following patch reads both mac
> > addresses.
> >
> > [PATCH 09/10] ARM: mx28: read fec mac address from ocotp
> >
> > +static int __init mx28evk_fec_get_mac(void)
> > +{
> > + int i, ret;
> > + u32 val;
> > +
> > + /*
> > + * OCOTP only stores the last 4 octets for each mac address,
> > + * so hard-coding the first two octets as Freescale OUI (00:04:9f)
> > + * is needed.
> > + */
> > + for (i = 0; i < 2; i++) {
> > + ret = mxs_read_ocotp(0x20 + i * 0x10, 1, &val);
> > + if (ret)
> > + goto error;
> > +
> > + mx28_fec_pdata[i].mac[0] = 0x00;
> > + mx28_fec_pdata[i].mac[1] = 0x04;
> > + mx28_fec_pdata[i].mac[2] = (val >> 24) & 0xff;
> > + mx28_fec_pdata[i].mac[3] = (val >> 16) & 0xff;
> > + mx28_fec_pdata[i].mac[4] = (val >> 8) & 0xff;
> > + mx28_fec_pdata[i].mac[5] = (val >> 0) & 0xff;
> uuh. Is ((val >> 24) & 0xff) supposed to be 0x9f? If not this might
> have unwanted effects (practical, don't know about legal ones).
Yes, it is 0x9f.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 03/10] net/fec: add mac field into platform data and consolidate fec_get_mac
From: Uwe Kleine-König @ 2010-12-29 10:37 UTC (permalink / raw)
To: Shawn Guo
Cc: Baruch Siach, davem, gerg, eric, bryan.wu, r64343, B32542, lw,
w.sang, s.hauer, linux-arm-kernel, netdev
In-Reply-To: <20101229103014.GD19347@freescale.com>
Hello,
On Wed, Dec 29, 2010 at 06:30:15PM +0800, Shawn Guo wrote:
> Sorry, Baruch. I missed two comments in the last reply.
>
> On Wed, Dec 29, 2010 at 08:53:30AM +0200, Baruch Siach wrote:
> > Hi Shawn,
> >
> > Please add netdev@vger.kernel.org to the Cc of all your fec driver patches.
> >
> I was aware of this after I sent out the patch set last night.
> Can I just resend all the patches in v2 and get netdev@vger.kernel.org
> included?
[I just added netdev for this reply. I think adding it for v2 is OK
then. For those interested, the whole series can be found at
http://thread.gmane.org/gmane.linux.ports.arm.kernel/100902
.]
> > On Tue, Dec 28, 2010 at 10:55:48PM +0800, Shawn Guo wrote:
> [...]
> > > + /*
> > > + * try to get mac address in following order:
> > > + *
> > > + * 1) kernel command line fec_mac=xx:xx:xx...
> > > + */
> > > + iap = fec_mac_default;
> > > +
> > > + /*
> > > + * 2) from flash or fuse (via platform data)
> > > + */
> >
> > Again, how do you handle the dual MAC case?
> >
> For the platform data case, the following patch reads both mac
> addresses.
>
> [PATCH 09/10] ARM: mx28: read fec mac address from ocotp
>
> +static int __init mx28evk_fec_get_mac(void)
> +{
> + int i, ret;
> + u32 val;
> +
> + /*
> + * OCOTP only stores the last 4 octets for each mac address,
> + * so hard-coding the first two octets as Freescale OUI (00:04:9f)
> + * is needed.
> + */
> + for (i = 0; i < 2; i++) {
> + ret = mxs_read_ocotp(0x20 + i * 0x10, 1, &val);
> + if (ret)
> + goto error;
> +
> + mx28_fec_pdata[i].mac[0] = 0x00;
> + mx28_fec_pdata[i].mac[1] = 0x04;
> + mx28_fec_pdata[i].mac[2] = (val >> 24) & 0xff;
> + mx28_fec_pdata[i].mac[3] = (val >> 16) & 0xff;
> + mx28_fec_pdata[i].mac[4] = (val >> 8) & 0xff;
> + mx28_fec_pdata[i].mac[5] = (val >> 0) & 0xff;
uuh. Is ((val >> 24) & 0xff) supposed to be 0x9f? If not this might
have unwanted effects (practical, don't know about legal ones).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: 2.6.37-rc7: Regression: b43: crashes in hwrng_register()
From: Maciej Rutecki @ 2010-12-29 10:30 UTC (permalink / raw)
To: Mario 'BitKoenig' Holbe, netdev; +Cc: linux-kernel
In-Reply-To: <slrnihjpnh.7t4.Mario.Holbe@darkside.dyn.samba-tng.org>
(CC added)
I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=25812
for your bug report, please add your address to the CC list in there, thanks!
On wtorek, 28 grudnia 2010 o 14:32:29 Mario 'BitKoenig' Holbe wrote:
> Hello,
>
> on 2.6.37-rc7 the b43 driver crashes in hwrng_register(). This makes the
> system virtually unusable since it appears to block networking syscalls.
> This leads to, for example, ifconfig never return.
> This issue does also exist in 2.6.37-rc5.
> This issue does not exist in 2.6.36.2.
>
> The hardware in question is:
> 02:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g
> LP-PHY [14e4:4315] (rev 01) on a Lenovo Ideapad S12 with VIA Nano.
>
> dmesg excerpt:
> [ 2.056847] b43-pci-bridge 0000:02:00.0: PCI INT A -> GSI 28 (level,
> low) -> IRQ 28 [ 2.056864] b43-pci-bridge 0000:02:00.0: setting latency
> timer to 64 ...
> [ 8.643695] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
> [ 9.047514] ieee80211 phy0: Selected rate control algorithm
> 'minstrel_ht' [ 9.048441] Registered led device: b43-phy0::tx
> [ 9.048479] Registered led device: b43-phy0::rx
> [ 9.048518] Registered led device: b43-phy0::radio
> [ 9.048542] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID:
> FW13 ] ...
> [ 24.312100] b43-phy0: Loading firmware version 410.2160 (2007-05-26
> 15:32:10) ...
> [ 29.848400] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
> [ 29.848407] b43-phy0: DMA mask fallback from 64-bit to 32-bit
> [ 29.868632] BUG: unable to handle kernel paging request at 907cde0c
> [ 29.868640] IP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core]
> [ 29.868655] *pde = 00000000
> [ 29.868659] Oops: 0000 [#1] SMP
> [ 29.868664] last sysfs file: /sys/bus/pci/drivers/parport_pc/uevent
> [ 29.868670] Modules linked in: parport_pc ppdev lp parport sbs sbshc
> power_meter pci_slot hed fan container acpi_cpufreq mperf
> cpufreq_conservative cpufreq_userspace cpufreq_stats cpufreq_powersave
> dm_crypt fuse loop eeprom via_cputemp i2c_dev nvram padlock_aes aes_i586
> aes_generic padlock_sha sha256_generic sha1_generic via_rng msr cpuid
> snd_hda_codec_realtek snd_hda_intel snd_hda_codec arc4 snd_hwdep ecb
> snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi b43 snd_rawmidi uvcvideo
> snd_seq_midi_event joydev videodev btusb snd_seq rng_core video ac battery
> tpm_tis v4l1_compat tpm tpm_bios output power_supply i2c_viapro snd_timer
> ideapad_laptop snd_seq_device serio_raw wmi mac80211 cfg80211 processor
> snd pcspkr i2c_core psmouse button bluetooth evdev shpchp soundcore
> snd_page_alloc rfkill pci_hotplug ext3 jbd mbcache raid10 raid456
> async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
> raid1 raid0 multipath linear md_mod dm_mirror dm_region_hash dm_log dm_mod
> btrfs zli b_deflate crc32c libcrc32c sd_mod crc_t10dif ata_generic
> uhci_hcd pata_via libata ssb ehci_hcd tg3 scsi_mod usbcore pcmcia
> via_sdmmc mmc_core pcmcia_core libphy thermal thermal_sys nls_base [last
> unloaded: scsi_wait_scan] [ 29.868810]
> [ 29.868816] Pid: 1781, comm: NetworkManager Not tainted 2.6.37-rc7-686
> #1 MoutCook/20021,2959 [ 29.868822] EIP: 0060:[<f8d543cc>] EFLAGS:
> 00010286 CPU: 0
> [ 29.868829] EIP is at hwrng_register+0x4c/0x139 [rng_core]
> [ 29.868834] EAX: 00000001 EBX: f4b17010 ECX: f6e5db6c EDX: f4b17035
> [ 29.868839] ESI: 907cddf0 EDI: 00000000 EBP: 00000036 ESP: f6e5db54
> [ 29.868844] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [ 29.868850] Process NetworkManager (pid: 1781, ti=f6e5c000 task=f6eb6080
> task.ti=f6e5c000) [ 29.868854] Stack:
> [ 29.868856] f4b16fc0 f4b17035 f8e5a870 f4b17035 0000001f f8e70095
> f8e6f9ca f4b71e70 [ 29.868866] 0000000f f6c95000 f6c95000 f6e97400
> f4b162c0 f4b10240 f4b16fc8 f8e5ad67 [ 29.868875] f89e43da f4b162c0
> f6cab400 f8b80e44 f6cab000 f8b70889 f8b6fe7a 00000000 [ 29.868884] Call
> Trace:
> [ 29.868909] [<f8e5a870>] ? b43_wireless_core_init+0xd0c/0xdd6 [b43]
> [ 29.868925] [<f8e5ad67>] ? b43_op_start+0xf8/0x142 [b43]
> [ 29.868947] [<f89e43da>] ? cfg80211_netdev_notifier_call+0x342/0x355
> [cfg80211] [ 29.868984] [<f8b70889>] ? ieee80211_do_open+0xed/0x45f
> [mac80211] [ 29.869002] [<f8b6fe7a>] ?
> ieee80211_check_concurrent_iface+0x1c/0x135 [mac80211] [ 29.869015]
> [<c11edcba>] ? __dev_open+0x7d/0xa7
> [ 29.869022] [<c11ec683>] ? __dev_change_flags+0x9a/0x10d
> [ 29.869028] [<c11edc12>] ? dev_change_flags+0x10/0x3b
> [ 29.869036] [<c11f7c77>] ? do_setlink+0x23e/0x532
> [ 29.869044] [<c11f803b>] ? rtnl_setlink+0xd0/0xe1
> [ 29.869058] [<c1145b00>] ? __strncpy_from_user+0x1d/0x2b
> [ 29.869064] [<c11f7f6b>] ? rtnl_setlink+0x0/0xe1
> [ 29.869069] [<c11f77a2>] ? rtnetlink_rcv_msg+0x186/0x19c
> [ 29.869075] [<c11f761c>] ? rtnetlink_rcv_msg+0x0/0x19c
> [ 29.869082] [<c1206818>] ? netlink_rcv_skb+0x2d/0x72
> [ 29.869088] [<c11f7616>] ? rtnetlink_rcv+0x18/0x1e
> [ 29.869093] [<c120666c>] ? netlink_unicast+0xba/0x10e
> [ 29.869099] [<c1207170>] ? netlink_sendmsg+0x23d/0x256
> [ 29.869111] [<c11dfe26>] ? __sock_sendmsg+0x48/0x4e
> [ 29.869117] [<c11e008f>] ? sock_sendmsg+0x78/0x8f
> [ 29.869123] [<c11e008f>] ? sock_sendmsg+0x78/0x8f
> [ 29.869131] [<c10c6785>] ? d_kill+0x38/0x3d
> [ 29.869141] [<c11e7f0c>] ? verify_iovec+0x3d/0x79
> [ 29.869147] [<c11e088d>] ? sys_sendmsg+0x15f/0x1c1
> [ 29.869153] [<c11e04c4>] ? sockfd_lookup_light+0x13/0x3f
> [ 29.869160] [<c11e0b25>] ? sys_sendto+0xfd/0x121
> [ 29.869166] [<c11e43eb>] ? sk_prot_alloc+0x62/0xd6
> [ 29.869174] [<c1001e6e>] ? __switch_to+0x6f/0xe2
> [ 29.869183] [<c12860de>] ? schedule+0x579/0x5b6
> [ 29.869190] [<c11e0723>] ? sys_recvmsg+0x3c/0x47
> [ 29.869196] [<c11e1afd>] ? sys_socketcall+0x17f/0x1cb
> [ 29.869202] [<c1002f9f>] ? sysenter_do_call+0x12/0x28
> [ 29.869206] Code: f8 e8 46 25 53 c8 8b 35 ec 45 d5 f8 eb 1a 8b 13 8b 06
> e8 17 11 3f c8 85 c0 75 0a be ef ff ff ff e9 d3 00 00 00 8b 76 1c 83 ee 1c
> <8b> 46 1c 0f 18 00 90 81 fe d0 45 d5 f8 75 d4 83 3d ec 47 d5 f8 [
> 29.869249] EIP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core] SS:ESP
> 0068:f6e5db54 [ 29.869259] CR2: 00000000907cde0c
> [ 29.869264] ---[ end trace 6719399ed79e8cc1 ]---
>
>
> regards
> Mario
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply
* Re: Bypass flow control problems
From: Pasi Kärkkäinen @ 2010-12-29 8:49 UTC (permalink / raw)
To: Alkis Georgopoulos; +Cc: netdev
In-Reply-To: <1293612435.1813.9.camel@alkis>
On Wed, Dec 29, 2010 at 10:47:15AM +0200, Alkis Georgopoulos wrote:
> ???????? 27-12-2010, ?????????? ??????, ?????? ?????? 15:43 +0200, ??/?? Pasi Kärkkäinen
> ????????????:
> > You could set up QoS rules on the server to limit the network speed per client..
>
> That sounds promising. I'll try to limit the rate of packages that the
> server sends to each client to 90 Mbps and see if that works around the
> flow control problem. Any tips for a good method to do that?
>
I guess you need to read the Linux Advanced Routing and Traffic Control howto..
it has examples how to use the Linux QoS stuff.
There are also some scripts out there that make it easier to set it up.
-- Pasi
^ permalink raw reply
* Re: dm9000 patch
From: Angelo Dureghello @ 2010-12-29 8:48 UTC (permalink / raw)
To: Baruch Siach; +Cc: netdev, linux-kernel
In-Reply-To: <20101229060637.GA31010@jasper.tkos.co.il>
On 29/12/2010 07:06, Baruch Siach wrote:
> Hi Angelo,
>
> On Tue, Dec 28, 2010 at 10:52:42PM +0100, Angelo Dureghello wrote:
>
>> sorry to contact you directly but i couldn't get any help from the
>> kernel.org mailing list, since i am not a developer my mails are
>> generally skipped.
>>
> The best way to get the contact info for a piece of kernel code, is using the
> get_maintainer.pl script. Running 'scripts/get_maintainer.pl -f
> drivers/net/dm9000.c' gives the following output:
>
> netdev@vger.kernel.org
> linux-kernel@vger.kernel.org
>
> I added both to Cc.
>
>
>> I am very near to have a custom board working with MCF5307 cpu and dm9000.
>> I am using kernel 2.6.36-rc3 with your last patch about
>> spinlock-recursion already included.
>>
> You should try to update to the latest .36 kernel, which is currently
> 2.6.36.2. The problem that you experience might be unrelated to the dm9000
> driver (or to networking at all), so it might have been fixed in this version.
>
>
>> I have "ping" and "telnet" to the embedded board fully working.
>> If i try to get a sample web page with some images from the board
>> httpd with a browser, in 80% of cases i get a trap/oops:
>>
> Try to enable KALLSYMS in your kernel .config to make your stack trace more
> meaningful. This is under 'General setup -> Configure standard kernel features
> (for small systems) -> Load all symbols for debugging/ksymoops'.
>
> I hope this helps.
>
> baruch
>
>
>> [ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
>> [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29
>> [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29,
>> .owner_cpu: 0
>> [ 67.630000] Stack from 00d7b914:
>> [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead
>> 00dec1d4 0000001d 00000000
>> [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2
>> 00c42c06 0015f6f9 00002704
>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
>> 00006188 00c42800 0002b312
>> [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
>> 000df21c 00c42c06 00000000
>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
>> 00cfc640 00006188 000096e8
>> [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
>> 00029d3a 0000001f 00c42800
>> [ 67.630000] Call Trace:
>> [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a]
>> [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6]
>> [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0]
>> [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e]
>> [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44]
>> [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218]
>> [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06
>> [ 67.630000] Stack from 00d7b934:
>> [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4
>> 0000001d 00c42c06 00002704
>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
>> 00006188 00c42800 0002b312
>> [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
>> 000df21c 00c42c06 00000000
>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
>> 00cfc640 00006188 000096e8
>> [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
>> 00029d3a 0000001f 00c42800
>> [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10
>> 00146fb8 00d7ba20 00029e84
>> [ 67.630000] Call Trace:
>> [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84]
>> [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482]
>> [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2]
>> [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6]
>> [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee]
>> [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]
>>
>> As i said, i was hoping in your patch but i sadly discovered it is
>> already included in this kernel version.
>> Hope you can give me some help or can forward me to an appropriate
>> mailing list.
>>
>
Hi Baruch and all,
many thanks for the help,
i am going to try 2.6.36.2 and KALLSYMS.
Anyway, my purpose now is to learn as much as possible the interrupt
handling and the spinlock part, and as much as possible about linux
drivers, since i am very interested to enter on this and be able to fix
issues and contribute.
regards,
angelo
^ permalink raw reply
* Re: Bypass flow control problems
From: Pasi Kärkkäinen @ 2010-12-29 8:47 UTC (permalink / raw)
To: Kirsher, Jeffrey T; +Cc: Alkis Georgopoulos, netdev@vger.kernel.org
In-Reply-To: <5BBF316A-A162-4683-B6CA-6662F221F500@intel.com>
On Tue, Dec 28, 2010 at 09:05:42PM -0800, Kirsher, Jeffrey T wrote:
> On Dec 27, 2010, at 8:43, Pasi Kärkkäinen <pasik@iki.fi> wrote:
>
> > On Wed, Dec 22, 2010 at 07:51:31PM +0200, Alkis Georgopoulos wrote:
> >> Hi,
> >>
> >> I'm an IT teacher/LTSP developer. In LTSP, thin clients are netbooted
> >> from a server and receive a lot of X and remote disk traffic from it.
> >>
> >> Many installations have a gigabit NIC on the server, an unmanaged
> >> gigabit switch, and 100 Mbps NICs on the clients.
> >>
> >> With flow control on, the server is limited to sending 100 Mbps to all
> >> the clients. So with 10 thin clients the server can concurrently send
> >> only 10 Mbps to each one of them.
> >>
> >> On NICs that support it, we turn flow control off and the server can
> >> properly send 100 Mbps to each client, i.e. 1 Gbps to 10 clients.
> >>
> >> * Is there any way to bypass that problem on NICs that do not support
> >> turning off flow control, like e.g. realteks?
> >> I.e. when a client sends a pause signal to the server, instead of the
> >> server pausing, to continue sending data to another client?
> >> Or even to limit the amound of data the server sends to each client,
> >> so that the clients never have to send pause signals?
> >>
> >
> > You could set up QoS rules on the server to limit the network speed per client..
> >
> >> * I really don't understand why flow control is enabled by default on
> >> NICs and switches. In which case does it help? As far as I
> >> understand, all it does is ruin gigabit => 100 Mbps connections...
> >>
> >> * As a side note, since rtl8169 is a very common chipset, is there a
> >> way to disable flow control for that specific NIC?
> >>
> >> This problem affects thousands of LTSP installations, we'd much
> >> appreciate your knowledge and feedback on it.
> >>
> >
> > Did you try disabling flow control from the switch?
>
> He stated the switch was a un-managed switch, so he would be unable to disable flow control on the switch.
>
Oh, I missed that :) Never mind then.
-- Pasi
^ permalink raw reply
* Re: Bypass flow control problems
From: Alkis Georgopoulos @ 2010-12-29 8:47 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: netdev
In-Reply-To: <20101227134346.GD2754@reaktio.net>
Στις 27-12-2010, ημέρα Δευ, και ώρα 15:43 +0200, ο/η Pasi Kärkkäinen
έγραψε:
> You could set up QoS rules on the server to limit the network speed per client..
That sounds promising. I'll try to limit the rate of packages that the
server sends to each client to 90 Mbps and see if that works around the
flow control problem. Any tips for a good method to do that?
Thank you.
^ permalink raw reply
* [PATCH v3 net-next-2.6] sch_sfq: allow big packets and be fair
From: Eric Dumazet @ 2010-12-29 7:53 UTC (permalink / raw)
To: David Miller; +Cc: jarkao2, kaber, netdev
In-Reply-To: <20101228.134655.112609314.davem@davemloft.net>
Le mardi 28 décembre 2010 à 13:46 -0800, David Miller a écrit :
> Eric this doesn't apply cleanly, since the code in sfq_dump_class_stats()
> is a bit different in net-next-2.6
>
> Please respin this and resubmit.
Sure, here is the version for latest net-next
Thanks
[PATCH v3 net-next-2.6] sch_sfq: allow big packets and be fair
SFQ is currently 'limited' to small packets, because it uses a 15bit
allotment number per flow. Introduce a scale by 8, so that we can handle
full size TSO/GRO packets.
Use appropriate handling to make sure allot is positive before a new
packet is dequeued, so that fairness is respected.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Jarek Poplawski <jarkao2@gmail.com>
Cc: Patrick McHardy <kaber@trash.net>
---
v3: respin after commit ee09b3c1cf (fix sfq class stats handling)
v2: Use a scale of 8 as Jarek suggested, instead of 18bit fields
net/sched/sch_sfq.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 0ce421d..79c8967 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -67,7 +67,7 @@
IMPLEMENTATION:
This implementation limits maximal queue length to 128;
- maximal mtu to 2^15-1; max 128 flows, number of hash buckets to 1024.
+ max mtu to 2^18-1; max 128 flows, number of hash buckets to 1024.
The only goal of this restrictions was that all data
fit into one 4K page on 32bit arches.
@@ -77,6 +77,11 @@
#define SFQ_SLOTS 128 /* max number of flows */
#define SFQ_EMPTY_SLOT 255
#define SFQ_HASH_DIVISOR 1024
+/* We use 16 bits to store allot, and want to handle packets up to 64K
+ * Scale allot by 8 (1<<3) so that no overflow occurs.
+ */
+#define SFQ_ALLOT_SHIFT 3
+#define SFQ_ALLOT_SIZE(X) DIV_ROUND_UP(X, 1 << SFQ_ALLOT_SHIFT)
/* This type should contain at least SFQ_DEPTH + SFQ_SLOTS values */
typedef unsigned char sfq_index;
@@ -115,7 +120,7 @@ struct sfq_sched_data
struct timer_list perturb_timer;
u32 perturbation;
sfq_index cur_depth; /* depth of longest slot */
-
+ unsigned short scaled_quantum; /* SFQ_ALLOT_SIZE(quantum) */
struct sfq_slot *tail; /* current slot in round */
sfq_index ht[SFQ_HASH_DIVISOR]; /* Hash table */
struct sfq_slot slots[SFQ_SLOTS];
@@ -395,7 +400,7 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
q->tail->next = x;
}
q->tail = slot;
- slot->allot = q->quantum;
+ slot->allot = q->scaled_quantum;
}
if (++sch->q.qlen <= q->limit) {
sch->bstats.bytes += qdisc_pkt_len(skb);
@@ -431,8 +436,14 @@ sfq_dequeue(struct Qdisc *sch)
if (q->tail == NULL)
return NULL;
+next_slot:
a = q->tail->next;
slot = &q->slots[a];
+ if (slot->allot <= 0) {
+ q->tail = slot;
+ slot->allot += q->scaled_quantum;
+ goto next_slot;
+ }
skb = slot_dequeue_head(slot);
sfq_dec(q, a);
sch->q.qlen--;
@@ -447,9 +458,8 @@ sfq_dequeue(struct Qdisc *sch)
return skb;
}
q->tail->next = next_a;
- } else if ((slot->allot -= qdisc_pkt_len(skb)) <= 0) {
- q->tail = slot;
- slot->allot += q->quantum;
+ } else {
+ slot->allot -= SFQ_ALLOT_SIZE(qdisc_pkt_len(skb));
}
return skb;
}
@@ -485,6 +495,7 @@ static int sfq_change(struct Qdisc *sch, struct nlattr *opt)
sch_tree_lock(sch);
q->quantum = ctl->quantum ? : psched_mtu(qdisc_dev(sch));
+ q->scaled_quantum = SFQ_ALLOT_SIZE(q->quantum);
q->perturb_period = ctl->perturb_period * HZ;
if (ctl->limit)
q->limit = min_t(u32, ctl->limit, SFQ_DEPTH - 1);
@@ -525,6 +536,7 @@ static int sfq_init(struct Qdisc *sch, struct nlattr *opt)
q->tail = NULL;
if (opt == NULL) {
q->quantum = psched_mtu(qdisc_dev(sch));
+ q->scaled_quantum = SFQ_ALLOT_SIZE(q->quantum);
q->perturb_period = 0;
q->perturbation = net_random();
} else {
@@ -617,7 +629,7 @@ static int sfq_dump_class_stats(struct Qdisc *sch, unsigned long cl,
if (idx != SFQ_EMPTY_SLOT) {
const struct sfq_slot *slot = &q->slots[idx];
- xstats.allot = slot->allot;
+ xstats.allot = slot->allot << SFQ_ALLOT_SHIFT;
qs.qlen = slot->qlen;
slot_queue_walk(slot, skb)
qs.backlog += qdisc_pkt_len(skb);
^ permalink raw reply related
* Re: dm9000 patch
From: Baruch Siach @ 2010-12-29 6:06 UTC (permalink / raw)
To: Angelo Dureghello; +Cc: netdev, linux-kernel
In-Reply-To: <4D1A5C2A.5050606@gmail.com>
Hi Angelo,
On Tue, Dec 28, 2010 at 10:52:42PM +0100, Angelo Dureghello wrote:
> sorry to contact you directly but i couldn't get any help from the
> kernel.org mailing list, since i am not a developer my mails are
> generally skipped.
The best way to get the contact info for a piece of kernel code, is using the
get_maintainer.pl script. Running 'scripts/get_maintainer.pl -f
drivers/net/dm9000.c' gives the following output:
netdev@vger.kernel.org
linux-kernel@vger.kernel.org
I added both to Cc.
> I am very near to have a custom board working with MCF5307 cpu and dm9000.
> I am using kernel 2.6.36-rc3 with your last patch about
> spinlock-recursion already included.
You should try to update to the latest .36 kernel, which is currently
2.6.36.2. The problem that you experience might be unrelated to the dm9000
driver (or to networking at all), so it might have been fixed in this version.
> I have "ping" and "telnet" to the embedded board fully working.
> If i try to get a sample web page with some images from the board
> httpd with a browser, in 80% of cases i get a trap/oops:
Try to enable KALLSYMS in your kernel .config to make your stack trace more
meaningful. This is under 'General setup -> Configure standard kernel features
(for small systems) -> Load all symbols for debugging/ksymoops'.
I hope this helps.
baruch
> [ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
> [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29
> [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29,
> .owner_cpu: 0
> [ 67.630000] Stack from 00d7b914:
> [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead
> 00dec1d4 0000001d 00000000
> [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2
> 00c42c06 0015f6f9 00002704
> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
> 00006188 00c42800 0002b312
> [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
> 000df21c 00c42c06 00000000
> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
> 00cfc640 00006188 000096e8
> [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
> 00029d3a 0000001f 00c42800
> [ 67.630000] Call Trace:
> [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a]
> [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6]
> [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0]
> [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e]
> [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44]
> [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218]
> [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06
> [ 67.630000] Stack from 00d7b934:
> [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4
> 0000001d 00c42c06 00002704
> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
> 00006188 00c42800 0002b312
> [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
> 000df21c 00c42c06 00000000
> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
> 00cfc640 00006188 000096e8
> [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
> 00029d3a 0000001f 00c42800
> [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10
> 00146fb8 00d7ba20 00029e84
> [ 67.630000] Call Trace:
> [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84]
> [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482]
> [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2]
> [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6]
> [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee]
> [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]
>
> As i said, i was hoping in your patch but i sadly discovered it is
> already included in this kernel version.
> Hope you can give me some help or can forward me to an appropriate
> mailing list.
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: Bypass flow control problems
From: Kirsher, Jeffrey T @ 2010-12-29 5:05 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: Alkis Georgopoulos, netdev@vger.kernel.org
In-Reply-To: <20101227134346.GD2754@reaktio.net>
On Dec 27, 2010, at 8:43, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Wed, Dec 22, 2010 at 07:51:31PM +0200, Alkis Georgopoulos wrote:
>> Hi,
>>
>> I'm an IT teacher/LTSP developer. In LTSP, thin clients are netbooted
>> from a server and receive a lot of X and remote disk traffic from it.
>>
>> Many installations have a gigabit NIC on the server, an unmanaged
>> gigabit switch, and 100 Mbps NICs on the clients.
>>
>> With flow control on, the server is limited to sending 100 Mbps to all
>> the clients. So with 10 thin clients the server can concurrently send
>> only 10 Mbps to each one of them.
>>
>> On NICs that support it, we turn flow control off and the server can
>> properly send 100 Mbps to each client, i.e. 1 Gbps to 10 clients.
>>
>> * Is there any way to bypass that problem on NICs that do not support
>> turning off flow control, like e.g. realteks?
>> I.e. when a client sends a pause signal to the server, instead of the
>> server pausing, to continue sending data to another client?
>> Or even to limit the amound of data the server sends to each client,
>> so that the clients never have to send pause signals?
>>
>
> You could set up QoS rules on the server to limit the network speed per client..
>
>> * I really don't understand why flow control is enabled by default on
>> NICs and switches. In which case does it help? As far as I
>> understand, all it does is ruin gigabit => 100 Mbps connections...
>>
>> * As a side note, since rtl8169 is a very common chipset, is there a
>> way to disable flow control for that specific NIC?
>>
>> This problem affects thousands of LTSP installations, we'd much
>> appreciate your knowledge and feedback on it.
>>
>
> Did you try disabling flow control from the switch?
He stated the switch was a un-managed switch, so he would be unable to disable flow control on the switch.
>
^ permalink raw reply
* Re: [PATCH net-next 2/3] dcbnl: adding DCBX feature flags get-set
From: John Fastabend @ 2010-12-29 0:15 UTC (permalink / raw)
To: Shmulik Ravid, davem@davemloft.net
Cc: eilong@broadcom.com, Liu, Lucy, netdev@vger.kernel.org
In-Reply-To: <1292959973.7142.131.camel@lb-tlvb-shmulik.il.broadcom.com>
On 12/21/2010 11:32 AM, Shmulik Ravid wrote:
> Adding a pair of set-get functions to dcbnl for setting the negotiation
> flags of the various DCB features. The user sets these flags (enable,
> advertise, willing) for each feature to be used by the device DCBX
> engine. The 'get' routine returns which of the features is enabled
> after the negotiation.
>
> Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Dave, these are going to conflict with my patches
[net-next-2.6,1/3] dcbnl: add support for ieee8021Qaz attributes
[net-next-2.6,2/3] dcbnl: add appliction tlv handlers
If needed either Shmulik or myself can work out the conflicts if you want a single series that applies cleanly.
Thanks,
John.
^ permalink raw reply
* Re: [PATCH net-next 1/3] dcbnl: adding DCBX engine capability
From: John Fastabend @ 2010-12-29 0:05 UTC (permalink / raw)
To: Shmulik Ravid
Cc: davem@davemloft.net, eilong@broadcom.com, Liu, Lucy,
netdev@vger.kernel.org
In-Reply-To: <1292959963.7142.130.camel@lb-tlvb-shmulik.il.broadcom.com>
On 12/21/2010 11:32 AM, Shmulik Ravid wrote:
> Adding an optional DCBX capability and a pair for get-set routines for
> setting the device DCBX mode. The DCBX capability is a bit field of
> supported attributes. The user is expected to set the DCBX mode with a
> subset of the advertised attributes.
>
>
> Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
> ---
> include/linux/dcbnl.h | 17 +++++++++++++++++
> include/net/dcbnl.h | 2 ++
> net/dcb/dcbnl.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 61 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
> index 8723491..974fd1e 100644
> --- a/include/linux/dcbnl.h
> +++ b/include/linux/dcbnl.h
> @@ -50,6 +50,8 @@ struct dcbmsg {
> * @DCB_CMD_SBCN: get backward congestion notification configration.
> * @DCB_CMD_GAPP: get application protocol configuration
> * @DCB_CMD_SAPP: set application protocol configuration
> + * @DCB_CMD_GDCBX: get DCBX engine configuration
> + * @DCB_CMD_SDCBX: set DCBX engine configuration
> */
> enum dcbnl_commands {
> DCB_CMD_UNDEFINED,
> @@ -83,6 +85,9 @@ enum dcbnl_commands {
> DCB_CMD_GAPP,
> DCB_CMD_SAPP,
>
> + DCB_CMD_GDCBX,
> + DCB_CMD_SDCBX,
> +
> __DCB_CMD_ENUM_MAX,
> DCB_CMD_MAX = __DCB_CMD_ENUM_MAX - 1,
> };
> @@ -102,6 +107,7 @@ enum dcbnl_commands {
> * @DCB_ATTR_CAP: DCB capabilities of the device (NLA_NESTED)
> * @DCB_ATTR_NUMTCS: number of traffic classes supported (NLA_NESTED)
> * @DCB_ATTR_BCN: backward congestion notification configuration (NLA_NESTED)
> + * @DCB_ATTR_DCBX: DCBX engine configuration in the device (NLA_U8)
> */
> enum dcbnl_attrs {
> DCB_ATTR_UNDEFINED,
> @@ -118,6 +124,7 @@ enum dcbnl_attrs {
> DCB_ATTR_NUMTCS,
> DCB_ATTR_BCN,
> DCB_ATTR_APP,
> + DCB_ATTR_DCBX,
>
> __DCB_ATTR_ENUM_MAX,
> DCB_ATTR_MAX = __DCB_ATTR_ENUM_MAX - 1,
> @@ -262,6 +269,8 @@ enum dcbnl_tc_attrs {
> * @DCB_CAP_ATTR_GSP: (NLA_U8) device supports group strict priority
> * @DCB_CAP_ATTR_BCN: (NLA_U8) device supports Backwards Congestion
> * Notification
> + * @DCB_CAP_ATTR_DCBX: (NLA_U8) device supports DCBX engine
> + *
> */
> enum dcbnl_cap_attrs {
> DCB_CAP_ATTR_UNDEFINED,
> @@ -273,11 +282,19 @@ enum dcbnl_cap_attrs {
> DCB_CAP_ATTR_PFC_TCS,
> DCB_CAP_ATTR_GSP,
> DCB_CAP_ATTR_BCN,
> + DCB_CAP_ATTR_DCBX,
>
> __DCB_CAP_ATTR_ENUM_MAX,
> DCB_CAP_ATTR_MAX = __DCB_CAP_ATTR_ENUM_MAX - 1,
> };
>
> +/* DCBX capabilities */
> +#define DCB_CAP_DCBX_HOST 0x01 /* host based DCBX engine support */
> +#define DCB_CAP_DCBX_HW 0x02 /* HW DCBX engine support */
> +#define DCB_CAP_DCBX_VER_CEE 0x04 /* HW DCBX supports CEE protocol */
> +#define DCB_CAP_DCBX_VER_IEEE 0x08 /* HW DCBX supports IEEE protocol */
> +#define DCB_CAP_DCBX_STATIC 0x10 /* HW DCBX supports static config */
> +
I would like to use these bits for guests using a VF as well. The problem is multiple lldp agents advertising dcbx tlvs on the same link is not spec compliant. In the VF case there may or may not be a hardware lldp engine all the VF driver (ie ixgbevf) should need to know is that some other entity is managing the DCB attributes.
To reflect this I would propose changing DCB_CAP_DCBX_HW and the comments by removing "HW". The two ideas I had were DCB_CAP_DCBX_READONLY or DCB_CAP_DCBX_LLD_MANAGED. Admittedly a bit of a nitpick but its a bit confusing to set the DCBX_HW bit when there really is no HW engine in the 82599 adapter case.
Otherwise this all looks good to me. I was hoping someone would get around to this. Thanks a lot!
-- John.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ifb: add performance flags to dev->features
From: Jarek Poplawski @ 2010-12-28 23:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, xiaosuo, pstaszewski, netdev
In-Reply-To: <1293575781.20573.391.camel@edumazet-laptop>
On Tue, Dec 28, 2010 at 11:36:21PM +0100, Eric Dumazet wrote:
> Le mardi 28 décembre 2010 ?? 13:50 -0800, David Miller a écrit :
>
> > Changli has suggested that these flags can also be set in
> > ->vlan_features, please address that if you expect me to
> > apply the change.
>
> Hmm, I am just scratching my head to actually setup vlans on top of ifb,
> to test such a change ?
Ingress is before vlans handler so these features and the
NETIF_F_HW_VLAN_TX flag seem useful for ifb considering
dev_hard_start_xmit() checks.
Jarek P.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ifb: add performance flags to dev->features
From: Eric Dumazet @ 2010-12-28 22:36 UTC (permalink / raw)
To: David Miller; +Cc: xiaosuo, jarkao2, pstaszewski, netdev
In-Reply-To: <20101228.135013.39173075.davem@davemloft.net>
Le mardi 28 décembre 2010 à 13:50 -0800, David Miller a écrit :
> Changli has suggested that these flags can also be set in
> ->vlan_features, please address that if you expect me to
> apply the change.
Hmm, I am just scratching my head to actually setup vlans on top of ifb,
to test such a change ?
^ permalink raw reply
* Re: [patch] net/unix: do not forget to autobind in standard case
From: David Miller @ 2010-12-28 21:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: jengelh, netdev
In-Reply-To: <1293554655.20573.5.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 28 Dec 2010 17:44:15 +0100
> Le samedi 25 décembre 2010 à 01:08 +0100, Jan Engelhardt a écrit :
>> parent 67514fc40bbec857018cbc689d440282b75551db (v2.6.37-rc1-229-g67514fc)
>> commit 973bdc63c6aba703dd7b62a6ec7ae4bab7847731
>> Author: Jan Engelhardt <jengelh@medozas.de>
>> Date: Sat Dec 25 00:50:59 2010 +0100
>>
>> net/unix: do not forget to autobind in standard case
>>
>> A program using recvmsg on an AF_LOCAL datagram socket does not
>> receive the peer's address when the remote has not issued a bind. This
>> makes it impossible to send messages back. (But the same _does_ work
>> in IP.) The cause for this is because autobinding was only done when
>> credential passing was requested.
>>
>
> It would be good you did some research and tell us why current code
> tests SOCK_PASSCRED
>
> There must be a reason this restrictive code is here, dont you think ?
I definitely think that test is intentional. I'm not applying this
without at least some basic research.
^ permalink raw reply
* Re: [patch] skfp: testing the wrong variable in skfp_driver_init()
From: David Miller @ 2010-12-28 21:55 UTC (permalink / raw)
To: jpirko; +Cc: error27, netdev, eric.dumazet, hsweeten, kernel-janitors
In-Reply-To: <20101224084538.GA2791@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Fri, 24 Dec 2010 09:45:39 +0100
> Fri, Dec 24, 2010 at 06:17:34AM CET, error27@gmail.com wrote:
>>The intent here was to test if the allocation failed but we tested
>>"SharedMemSize" instead of "SharedMemAddr" by mistake.
>>
>>Signed-off-by: Dan Carpenter <error27@gmail.com>
>>
>>diff --git a/drivers/net/skfp/skfddi.c b/drivers/net/skfp/skfddi.c
>>index 0a66fed..16c6265 100644
>>--- a/drivers/net/skfp/skfddi.c
>>+++ b/drivers/net/skfp/skfddi.c
>>@@ -412,7 +412,7 @@ static int skfp_driver_init(struct net_device *dev)
>> bp->SharedMemAddr = pci_alloc_consistent(&bp->pdev,
>> bp->SharedMemSize,
>> &bp->SharedMemDMA);
>>- if (!bp->SharedMemSize) {
>>+ if (!bp->SharedMemAddr) {
>> printk("could not allocate mem for ");
>> printk("hardware module: %ld byte\n",
>> bp->SharedMemSize);
>
> Looks obvious.
>
> Reviewed-by: Jiri Pirko <jpirko@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ppp: allow disabling multilink protocol ID compression
From: David Miller @ 2010-12-28 21:53 UTC (permalink / raw)
To: paulus; +Cc: shemminger, linux-ppp, netdev
In-Reply-To: <20101221224400.GA17383@brick.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Wed, 22 Dec 2010 09:44:00 +1100
> On Mon, Dec 20, 2010 at 07:58:33PM -0800, Stephen Hemminger wrote:
>
>> Linux would not connect to other router running old version Cisco IOS (12.0).
>> This is most likely a bug in that version of IOS, since it is fixed
>> in later versions. As a workaround this patch allows a module parameter
>> to be set to disable compressing the protocol ID.
>>
>> See: https://bugzilla.vyatta.com/show_bug.cgi?id=3979
>>
>> RFC 1990 allows an implementation to formulate MP fragments as if protocol
>> compression had been negotiated. This allows us to always send compressed
>> protocol IDs. But some implementations don't accept MP fragments with
>> compressed protocol IDs. This parameter allows us to interoperate with
>> them. The default value of the configurable parameter is the same as the
>> current behavior: protocol compression is enabled. If protocol compression
>> is disabled we will not send compressed protocol IDs.
>>
>> This is based on an earlier patch by Bob Gilligan (using a sysctl).
>> Module parameter is writable to allow for enabling even if ppp
>> is already loaded for other uses.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Acked-by: Paul Mackerras <paulus@samba.org>
Applied, thanks.
^ permalink raw reply
* RE: [patch] vxge: remove duplicated part of check {nodisc}
From: Ramkrishna Vepa @ 2010-12-28 21:51 UTC (permalink / raw)
To: Dan Carpenter
Cc: Sivakumar Subramani, Sreenivasa Honnur, Jon Mason,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <20101224061539.GP1936@bicker>
> This is just a cleanup to make the static checkers happy. We don't need
> to check "own" twice.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/drivers/net/vxge/vxge-traffic.c b/drivers/net/vxge/vxge-
> traffic.c
> index 42cc298..4c10d6c 100644
> --- a/drivers/net/vxge/vxge-traffic.c
> +++ b/drivers/net/vxge/vxge-traffic.c
> @@ -1240,7 +1240,7 @@ enum vxge_hw_status vxge_hw_ring_rxd_next_completed(
> *t_code = (u8)VXGE_HW_RING_RXD_T_CODE_GET(control_0);
>
> /* check whether it is not the end */
> - if (!own || ((*t_code == VXGE_HW_RING_T_CODE_FRM_DROP) && own)) {
> + if (!own || *t_code == VXGE_HW_RING_T_CODE_FRM_DROP) {
>
> vxge_assert(((struct vxge_hw_ring_rxd_1 *)rxdp)->host_control
> !=
> 0);
Looks good, thanks.
Acked-by: Ram Vepa <ram.vepa@exar.com>
^ permalink raw reply
* Re: [PATCH] ehea: Avoid changing vlan flags
From: David Miller @ 2010-12-28 21:51 UTC (permalink / raw)
To: leitao; +Cc: shemminger, netdev, jesse
In-Reply-To: <1292871757-24918-1-git-send-email-leitao@linux.vnet.ibm.com>
From: leitao@linux.vnet.ibm.com
Date: Mon, 20 Dec 2010 17:02:37 -0200
> This patch avoids disabling the vlan flags using ethtool.
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Applied.
Although in the long term, having each and every driver handle this
seems rediculious.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ifb: add performance flags to dev->features
From: David Miller @ 2010-12-28 21:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, jarkao2, pstaszewski, netdev
In-Reply-To: <1292855120.2800.45.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 20 Dec 2010 15:25:20 +0100
> Le lundi 20 décembre 2010 à 22:05 +0800, Changli Gao a écrit :
>> 2010/12/20 Jarek Poplawski <jarkao2@gmail.com>:
>> >
>> > IMHO it should, (probably even more, like loopback) but we should
>> > consider mirred can xmit to other than ifb too.
>> >
>>
>> I also think so. And when making ifb a multiqueue NIC, I tried to add
>> these dev features to ifb. :)
>>
>
> This has litle to do with your multiqueue work,
> its more an effect of GRO being more and more deployed.
>
> I dont see dev->features being changed in one of your previous patches.
> I did dummy case in commit 6d81f41c58c6
>
> [PATCH net-next-2.6] ifb: add performance flags to dev->features
>
> IFB can use the full set of features flags (NETIF_F_SG |
> NETIF_F_FRAGLIST | NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA) to
> avoid unecessary split of some packets (GRO for example)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Changli has suggested that these flags can also be set in
->vlan_features, please address that if you expect me to
apply the change.
^ permalink raw reply
* Re: [PATCH] ip: reuse ip_summed of first fragment for all subsequent fragments
From: David Miller @ 2010-12-28 21:49 UTC (permalink / raw)
To: timo.lindfors; +Cc: netdev
In-Reply-To: <1292841525-15572-1-git-send-email-timo.lindfors@iki.fi>
From: Timo Juhani Lindfors <timo.lindfors@iki.fi>
Date: Mon, 20 Dec 2010 12:38:45 +0200
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 439d2a3..c0743ed 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -1167,7 +1167,7 @@ ssize_t ip_append_page(struct sock *sk, struct page *page,
> /*
> * Fill in the control structures
> */
> - skb->ip_summed = CHECKSUM_NONE;
> + skb->ip_summed = skb_prev->ip_summed;
> skb->csum = 0;
> skb_reserve(skb, hh_len);
You can't just assign skb_prev->ip_summed here, if it's CHECKSUM_PARTIAL
then things will go completely wrong. This is especially true since
we're about to zero out skb->csum.
^ permalink raw reply
* Re: [PATCH v2 net-next-2.6] sch_sfq: allow big packets and be fair
From: David Miller @ 2010-12-28 21:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: jarkao2, kaber, netdev
In-Reply-To: <1292936699.2720.23.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 21 Dec 2010 14:04:59 +0100
> Le mardi 21 décembre 2010 à 12:17 +0000, Jarek Poplawski a écrit :
>
>> Oops! You're right yet ;-) This skipping shouldn't happen with quantum
>> bigger than max packet size, so this patch is OK.
>
> Thanks Jarek, here is a v2 with the scale you suggested.
>
> [PATCH v2 net-next-2.6] sch_sfq: allow big packets and be fair
>
> SFQ is currently 'limited' to small packets, because it uses a 15bit
> allotment number per flow. Introduce a scale by 8, so that we can handle
> full size TSO/GRO packets.
>
> Use appropriate handling to make sure allot is positive before a new
> packet is dequeued, so that fairness is respected.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Jarek Poplawski <jarkao2@gmail.com>
> Cc: Patrick McHardy <kaber@trash.net>
> ---
> v2: Use a scale of 8 as Jarek suggested, instead of 18bit fields
Eric this doesn't apply cleanly, since the code in sfq_dump_class_stats()
is a bit different in net-next-2.6
Please respin this and resubmit.
^ 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