-l
45
> $ grep "= {0};" kernel/ -nr | wc -l
> 4
$ egrep -nr "=[[:space:]]*{[[:space:]]*0[[:space:]]*};" kernel | wc -l
8
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
There is NO CLOUD, just other people's computers. - FSFE
LUGA : http://www.luga.at
anything it is
increased (I need to verify that).
Not to worry, I guess I can now with your helpful pointer sort that
out with Redhat.
gruss
Bernd
seem to have 100 (filled) inflight segments.
Gruss
Bernd
--
http://bernd.eckenfels.net
hared keys,
by returning EOPNOTSUPP. However, pairwise keys are
still handled by hardware which works just fine.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 93 ++--
1 file changed, 4 insertions(+), 89 deletions(-)
diff --git a/d
beacon was received.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
v2: Improve patch description.
v3: Improve patch description, mention that dm.undec_sm_pwdb
is not used when no beacon received.
Make the title fit in one line.
v4: Try to fix the line
This patch moves the clearing of rtlpriv->link_info.num_rx_inperiod in
rtl_watchdog_wq_callback a few lines down.
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Sign
: Bernd Edlinger
---
v2: Improved patch description.
v3: Make the title fit in one line.
v4: Try to fix the line endings the message body.
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
2 files changed, 10 insertions
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
v2: Adjust the defaults of swlps and fwlps module
parameters to match the firmware capabilities instead of removing
-activated once a firmware
update is available.
v3: Make the title of each patch fit in one line.
v4: Try to fix the line endings the message body.
Which is an exchange server issue.
The patch does not change at all.
Bernd Edlinger (4):
rtl8723ae: Take the FW LPS mode handling out
On 1/8/19 6:27 PM, Kalle Valo wrote:
> Bernd Edlinger writes:
>
>> This appears to trigger a firmware bug and causes severe
>> problems with rtl8723ae PCI devices.
>>
>> When the power save mode is activated for longer periods
>> of time the firmware stop
beacon was received.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
v2: Improve patch description.
v3: Improve patch description, mention that dm.undec_sm_pwdb
is not used when no beacon received.
Make the title fit in one line.
---
.../net/wireless
This patch moves the clearing of rtlpriv->link_info.num_rx_inperiod in
rtl_watchdog_wq_callback a few lines down.
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Sign
: Bernd Edlinger
---
v2: Improved patch description.
v3: Make the title fit in one line.
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/realtek
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
v2: Adjust the defaults of swlps and fwlps module
parameters to match the firmware capabilities instead of removing
-activated once a firmware
update is available.
v3: Make the title of each patch fit in one line.
Bernd Edlinger (4):
rtl8723ae: Take the FW LPS mode handling out
rtl8723ae: Dont use old data for input gain control
rtl8723ae: Re-introduce the adaptive rate control
rtlwifi: Don't
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
di
rtlpriv->link_info.num_rx_inperiod in rtl_watchdog_wq_callback a few lines
down
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Signed-off-by: Bernd Edlinger
---
driv
rtl8723e_dm_refresh_rate_adaptive_mask
This function was present in a previous version of the code base,
it works just fine for me -- as long as it is not using stale data.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
.../net/wireless/realtek
pre_cck_fa_state/cur_cck_fa_state in
rtl_dm_diginit.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi
-activated once a firmware
update is available.
Bernd Edlinger (4):
rtlwifi: rtl8723ae: Take the FW LPS mode handling out
rtlwifi: rtl8723ae: Don't use dm.undec_sm_pwdb for input gain control
when no beacon was received in the connected state
rtlwifi: rtl8723ae: Re-intr
ly activated when there _is_ busy traffic, the next
packet did usually wake the firmware, rarely it did freeze however.
Other things like changing the cck_packet_detection_threshold or
refresh_rate_adaptive_mask
can also kick the firmware back to life.
Hope this helps to track down the root cause of this bug.
Thanks
Bernd.
On 1/5/19 3:44 AM, Larry Finger wrote:
> On 1/4/19 6:48 AM, Bernd Edlinger wrote:
>> This appears to trigger a firmware bug and causes severe
>> problems with rtl8723ae PCI devices.
>>
>> When the power save mode is activated for longer periods
>> of time the firm
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw.c| 20
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw
gain control when no beacon was received in the connected state.
This avoids sporadic "Connection to AP ... lost" errors.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
rtlpriv->link_info.num_rx_inperiod in rtl_watchdog_wq_callback a few lines
down.
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Signed-off-by: Bernd Edlinger
-
rtl8723e_dm_refresh_rate_adaptive_mask
This function was present in a previous version of the code base,
it works just fine for me -- as long as it is not using stale data.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
.../net/wireless/realtek
rtl8723ae PCI card in my laptop
against a FRITZ!Box 7590 AP -- the WiFi connection works now
very reliable for me.
Bernd Edlinger (4):
rtlwifi: rtl8723ae: Take the FW LPS mode handling out
rtlwifi: rtl8723ae: Don't use dm.undec_sm_pwdb for input gain control
when no beaco
b.
Signed-off-by: Oliver Zweigle
Signed-off-by: Bernd Eckstein <3ernd.eckst...@gmail.com>
---
drivers/net/usb/ipheth.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index 7275761..3d8a70d 100644
--- a
started between v4.5 and v4.6
and prevails up to v4.14.
Using the dirty_tx before acquiring the spin lock is clearly
wrong and was first introduced with v4.6.
Fixes: e3ad57c96715 ("stmmac: review RX/TX ring management")
Signed-off-by: Bernd Edlinger
---
drivers/net/ethernet/stmi
Signed-off-by: Bernd Edlinger
---
drivers/net/phy/Kconfig| 5 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/uPD60620.c | 109 +
3 files changed, 115 insertions(+)
create mode 100644 drivers/net/phy/uPD60620.c
diff --git a/drivers/net
DE: All speeds, HD in parallel detect */
+ return phy_write(phydev, PHY_SPM, 0x0180 | phydev->mdio.addr);
>>
>> Signed-off-by: Bernd Edlinger
>
> Please send this is a new patch. If we were to take this is is, all
> the comments above would end up in the co
On 09/22/17 19:59, Andrew Lunn wrote:
> On Fri, Sep 22, 2017 at 05:08:45PM +0000, Bernd Edlinger wrote:
>>
>> +config RENESAS_PHY
>> +tristate "Driver for Renesas PHYs"
>> +---help---
>> + Supports the uPD60620 and uPD60620A PHYs.
>>
Signed-off-by: Bernd Edlinger
---
drivers/net/phy/Kconfig| 5 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/uPD60620.c | 226
+
3 files changed, 232 insertions(+)
create mode 100644 drivers/net/phy/uPD60620.c
diff --git a/drivers
candidates and/or put patches in place.
* Does someone have seen this too? Can provide a better workaround, or patch or
anything?
* Where to file/reopen this issue? qemu, netdev?
* Is qemu-kvm even the right place to look for answers?
We are happy to provide more information or collect debug info
frequency to 25MHz, where before the upgrade it was set to 96MHz. Intel
confirmed that the correct frequency for this network adapter is 96MHz.
Signed-off-by: Bernd Faust
---
drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/intel
On Sat, Nov 12, 2016 at 09:02:24PM -0500, David Miller wrote:
> From: Kast Bernd
> Date: Fri, 4 Nov 2016 00:33:06 +0100
>
> > This patch adds a module parameter in order to activate ASPM. By that
> > the CPU can enter deep sleep modes (PC6) and power consumption can be
>
,
which wasn't respected on the previous patch. Thus ASPM with
this patch could work even with previously failing systems.
Signed-off-by: Kast Bernd
---
drivers/net/ethernet/realtek/r8169.c | 100 ---
1 file changed, 92 insertions(+), 8 deletions(-)
diff
s.
Should I add support for newer cards, too?
Is there any chance to enable ASPM by default again?
Which improvements do I need to do in order to get this patch to the
kernel again?
I would appreciate any kind of feedback.
Signed-off-by: Kast Bernd
---
drivers/net/ethernet/realtek/r8169.c | 82
ous issues with constraint I mentions in the previous mail:
"- MRs can have a maximum size of the memory available under linux"
The requirement is not met that the memory region must not be
larger then the available memory for that partition. The "create MR"
H_CALL will fails
On Saturday 16 February 2008, Kok, Auke wrote:
> Bernd Schubert wrote:
> > Hello,
> >
> > I can't login to one of our servers and just got this in an ipmi sol
> > session:
> >
> > [18169.209181] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
ome
reasons I would prefer not to reboot now.
Thanks,
Bernd
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
_MEM_SECTIONS)
- Maybe some kind of new interface?
What would you suggest?
Regards,
Jan-Bernd & Christoph
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Patch for eHEA memory hotplug support that uses these functions:
http://www.spinics.net/lists/netdev/msg54484.html
Signed-off-by: Jan-Bernd Themann
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
Hi,
this is the modified version with EXPORT_SYMBOL_GPL
Regards,
Jan-Bernd
driver
On Monday 11 February 2008 11:12, Dave Hansen wrote:
> On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> > are you the right person to address this patch to?
>
> You might want to check the top of the file. ;)
>
> > --- a/drivers/base/memory.c
> &g
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
Hi Greg,
are you the right person to address this patch to?
Regards,
Jan-Bernd
driver
t" label of
> __lro_proc_skb()) The comment says "Original SKB has to be posted to stack".
> I would be wrong, but I don't get the reason to possible change of ip_summed.
>
Good point. This assignment seems to be unnecessary.
Regards,
Jan-Bernd
--
To unsub
On Monday 04 February 2008 15:46, Michael Ellerman wrote:
> On Mon, 2008-02-04 at 14:04 +0100, Jan-Bernd Themann wrote:
> > Add memory remove hotplug support
> > @@ -3559,6 +3578,10 @@ int __init ehea_module_init(void)
> > if (ret)
> > ehea_info("fa
Add memory remove hotplug support
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
Comment: This patch depends on the following patch that
exports the symbols
register_memory_notifier()
unregister_memory_notifier()
http://lkml.org/lkml/2008/2/1/293
drivers/net/ehea/ehea_
tored there. The arrays are
kept up-to-date during normal runtime. The crash handler fn is triggered by the
recently introduced PPC crash shutdown reg/unreg functions.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h | 34 +-
drivers/net/ehea/ehea_ma
l.org/lkml/2008/2/1/293
Regards,
Jan-Bernd
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
p checksum checking for this kind of traffic (TCP)
There are two modes: aggregating SKBs or aggregating fragments.
When fragments are aggregated, there is no SKB with a filled ip_summed
available.
Please outline which parts of which mode you suggest to change.
Regards,
Jan-Bernd
--
To unsubscribe
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
Comment: eHEA patches that exploit these functions will follow
drivers/base/memory.c
Due to changes in the struct device_driver there is no direct
access to its kobj any longer. The kobj was used to create
sysfs links between eHEA ethernet devices and the driver.
This patch removes the affected sysfs links to resolve
the build problems.
Signed-off-by: Jan-Bernd Themann <[EM
On Fri, Nov 16, 2007 at 12:38:22PM +0100, Eric Dumazet wrote:
> Hello Bernd
>
> I did some investigations on the "netstat -s" problem and one
> fix is to change the size of char buf1[1024], buf2[1024];
I changed it now to 2048, and included your page aligend io buffer pat
=NULL and we
return anyway, more packets are in the receive queue and the stack won't call
poll again
until the next interrupt occurs. Received packets might stay unprocessed for
quite
some time in the queue.
In case there are more resources (SKBs) from send side
to be freed we'll do an e
eHEA resources that are allocated via H_CALLs have a unique identifier each.
These identifiers are necessary to free the resources. A reboot notifier
is used to free all eHEA resources before the indentifiers get lost, i.e
before kexec starts a new kernel.
Signed-off-by: Jan-Bernd Themann <[EM
eHEA recovery and DLPAR functions are called seldomly. The eHEA workqueues
are replaced by the kernel event queue.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
The patch has been built against upstream git
drivers/net/ehea/ehea.h |3 +--
drivers/net/ehea/ehea_main.c
Hi,
On Monday 01 October 2007 16:44, Jeff Garzik wrote:
> Jan-Bernd Themann wrote:
> > Due to stability issues in high load situations the HW queue handling
> > has to be changed. The HW queues are now stopped and restarted again instead
> > of destroying and all
cal
> (memory hotplug and driver reset), can we just use schedule_work?
>
Yes. I'll provide a patch soon.
Thanks,
Jan-Bernd
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Due to stability issues in high load situations the HW queue handling
has to be changed. The HW queues are now stopped and restarted again instead
of destroying and allocating new HW queues.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h
When I applied this netif_rx_reschedule fix this problem did not occur
anymore (module could be unloaded). So I guess I hit the problem you
described.
Thanks,
Jan-Bernd
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Update of ehea_poll function to work with new NAPI scheme.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
Hi David,
this patch is built upon the patches provided by Mel Gorman
(2.6.23-rc6-mm1: Build failure on ppc64 drivers/net/ehea/ehea_main.c)
and Roland Dreier
([PATCH net-
=99
CPU1: F. net_rx_action: set qutoa=99 - 99 = 0
CPU1: G. modify list (list_move_tail) altough netif_rx_complete has been called
Step G would fail as the device is not in the list due
to netif_rx_complete. This case can occur for all
devices running on an SMP system where interrupts are not pinned
eme of NAPI as it is
done for the RX side.
One other thing I observed is that I can not unload the module as the
ref counter of the eth device is too low. I haven't tracked down the
source of this problem yet.
Regards,
Jan-Bernd
-
To unsubscribe from this list: send the line "unsubscribe
Update last_rx in registered device struct instead of
in the dummy device.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_
the physical
port state is. Thus eHEA can be considered as a switch there.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |5 -
drivers/net/ehea/ehea_main.c | 14 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff -
return value of poll to determine
if the device has to be polled again or not.
We can either switch back or in case we want to stick to
the new return value, we might have to add something similar to
the NAPI_STATE_SCHED flag or a new parameter...
Regards,
Jan-Bernd
-
To unsubscribe from this
On Wednesday 29 August 2007 10:15, James Chapman wrote:
> Jan-Bernd Themann wrote:
> > What I'm trying to improve with this approach is interrupt
> > mitigation for NICs where the hardware support for interrupt
> > mitigation is limited. I'm not trying to improve t
On Wednesday 29 August 2007 10:29, David Miller wrote:
> From: Jan-Bernd Themann <[EMAIL PROTECTED]>
> Date: Wed, 29 Aug 2007 09:10:15 +0200
>
> > In the end I want to reduce the CPU utilization. And one way
> > to do that is LRO which also works only well if there ar
Hi David
David Miller schrieb:
Interrupt mitigation only works if it helps you avoid interrupts.
This scheme potentially makes more of them happen.
The hrtimer is just another interrupt, a cpu locally triggered one,
but it has much of the same costs nonetheless.
So if you set this timer, it tr
to call poll N times in a row when no
new packets arrive. There is no real delay as the net_rx_action function will
do nothing else between the poll calls.
Please correct me if I'm wrong.
Regards,
Jan-Bernd
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
U
(when no IRQ pinning is used). This is something the driver has to handle.
Regards,
Jan-Bernd
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 27 August 2007 22:37, David Miller wrote:
> From: Jan-Bernd Themann <[EMAIL PROTECTED]>
> Date: Mon, 27 Aug 2007 11:47:01 +0200
>
> > So the question is simply: Do we want drivers that need (benefit
> > from) a timer based polling support to implement th
On Monday 27 August 2007 17:51, James Chapman wrote:
> In the second half of my previous reply (which seems to have been
> deleted), I suggest a way to avoid this problem without using hardware
> interrupt mitigation / coalescing. Original text is quoted below.
>
> >> I've seen the same and I'
the physical
port state is. Thus eHEA can be considered as a switch there.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |5 -
drivers/net/ehea/ehea_main.c | 14 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff -
Update last_rx in registered device struct instead of
in the dummy device.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_
question is simply: Do we want drivers that need (benefit from)
a timer based polling support to implement their own timers each,
or should there be a generic support?
Thanks,
Jan-Bernd
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linas Vepstas schrieb:
On Fri, Aug 24, 2007 at 09:04:56PM +0200, Bodo Eggert wrote:
Linas Vepstas <[EMAIL PROTECTED]> wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
3) On modern systems the incoming packets are processed very fast. Especially
James Chapman schrieb:
Stephen Hemminger wrote:
On Fri, 24 Aug 2007 17:47:15 +0200
Jan-Bernd Themann <[EMAIL PROTECTED]> wrote:
Hi,
On Friday 24 August 2007 17:37, [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
...
3) On modern syste
Hi,
On Friday 24 August 2007 17:37, [EMAIL PROTECTED] wrote:
> On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
> > ...
> > 3) On modern systems the incoming packets are processed very fast.
> > Especially
> > on SMP systems when we use multip
usual timers are too slow. A finer granularity would be needed to keep the
latency down (and queue length moderate).
What do you think?
Thanks,
Jan-Bernd
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mor
le is called,
we will have the napi device scheduled twice again... because
net_rx_action will schedule it and netif_rx_schedule as well
(add it to poll_list).
I think this is an issue that can even occur if you don't use
netif_rx_reschedule. Do I understand this correctly?
Thanks,
Jan-B
Hi David,
On Thursday 23 August 2007 10:17, David Miller wrote:
> From: Jan-Bernd Themann <[EMAIL PROTECTED]>
> Date: Thu, 23 Aug 2007 08:55:29 +0200
>
> > We'd like to keep the possibility to switch back to a single queue
> > for now.
>
> Please do not
roperly.
> >
> >
> >> Also, on this code, in ehea_sense_port_attr()
> >>
> >> /* Number of default QPs */
> >> if (use_mcs)
> >> port->num_def_qps = cb0->num_default_qps;
> >> else
> >&g
the physical
port state is. Thus eHEA can be considered as a switch there.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |5 -
drivers/net/ehea/ehea_main.c | 14 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff -
Update the module parameter description of "use_mcs" to
show correct default value
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/
Includes hcp_epas_dtor in eq/cq/qp destructors to unmap
HW register.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_qmr.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
Userspace DLPAR tool expects decimal numbers to be written to
and read from sysfs entries.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/d
Hi
On Friday 10 August 2007 00:00, David Miller wrote:
> From: Auke Kok <[EMAIL PROTECTED]>
> Date: Thu, 09 Aug 2007 09:41:17 -0700
>
> > Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
>
> I think this is definitely how we should handle LRO
> configuration instead of the ad-hoc module parameters
>
Hi Jörn
On Friday 03 August 2007 15:41, Jörn Engel wrote:
> On Fri, 3 August 2007 14:41:19 +0200, Jan-Bernd Themann wrote:
> >
> > This patch provides generic Large Receive Offload (LRO) functionality
> > for IPv4/TCP traffic.
> >
> > LRO combines received t
Hi Auke,
On Friday 03 August 2007 22:29, Kok, Auke wrote:
> Jan-Bernd Themann wrote:
> > This patch shows how the generic LRO interface is used for SKB mode
> >
> > Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
> >
> > ---
> > drivers/net/
This patch shows how the generic LRO interface is used for SKB mode
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |1 +
drivers/net/ehea/ehea.h |9 -
drivers/net/ehea/ehea_ethtool.c | 15 +++
drivers/net/ehea/ehea_
either pass
SKBs or fragment lists to the LRO engine.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
include/linux/inet_lro.h | 177 ++
net/ipv4/Kconfig |8 +
net/ipv4/Makefile|1 +
net/ipv4/inet_lro.c
interface.
Thanks a lot,
Jan-Bernd
[PATCH 1/1] lro: Generic Large Receive Offload for TCP traffic
Changes to http://www.spinics.net/lists/netdev/msg37084.html
1) Fixed the LRO_MAX_PG_HLEN bug
2) skb->ip_summed can now be defined by driver for aggregated packets
3) The problem that the
Hi,
Thanks for finding these bugs! I'll post an updated version soon (2 patches
with no separate Kconfig patches, one LRO and one eHEA patch). See comments
below.
Thanks,
Jan-Bernd
On Monday 30 July 2007 22:32, Andrew Gallatin wrote:
> I was working on testing the myri10ge patch, a
Added LRO support using the "SKB aggregate" interface
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |9 -
drivers/net/ehea/ehea_ethtool.c | 15 +++
drivers/net/ehea/ehea_main.c| 82 +++
Kconfig changes for LRO
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f8a602c..fec4004 100644
--- a/drivers/net/Kconfig
+++ b/drive
default.
Is that ok?
Thanks,
Jan-Bernd
[PATCH 1/4][RFC] lro: Generic Large Receive Offload for TCP traffic
[PATCH 2/4][RFC] lro: Kconfig and Makefile
[PATCH 3/4][RFC] ehea: LRO support
[PATCH 4/4][RFC] ehea: Kconfig
Changes to http://www.spinics.net/lists/netdev/msg36912.html
1) A new field called
Kconfig and Makefile for LRO
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
net/ipv4/Kconfig |8
net/ipv4/Makefile |1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index fb79097..d894f61 100644
--- a/ne
1 - 100 of 238 matches
Mail list logo
