Dear,

Dear, please i am still waiting to hear form you after sending the second message to you

[PATCH net-next v3 3/3] net/udpgso_bench.sh test fails on error

Ensure that failure on any individual test results in an overall failure of the test script. Signed-off-by: Fred Klassen --- tools/testing/selftests/net/udpgso_bench.sh | 33 + 1 file changed, 33 insertions(+) diff --git a/tools/testing/selftests/net/udpgso_bench.sh

[PATCH net-next v3 2/3] net/udpgso_bench.sh add UDP GSO audit tests

: Unexpected number of Zerocopy completions:493706 expected493704 received Also reduce individual test time from 4 to 3 seconds so that overall test time does not increase significantly. v3: Enhancements as per Willem de Bruijn - document -P option for TCP audit Signed-off-by: Fred

[PATCH net-next v3 1/3] net/udpgso_bench_tx: options to exercise TX CMSG

MSG_TRUNC - general code cleanup Signed-off-by: Fred Klassen --- tools/testing/selftests/net/udpgso_bench_tx.c | 291 -- 1 file changed, 276 insertions(+), 15 deletions(-) diff --git a/tools/testing/selftests/net/udpgso_bench_tx.c b/tools/testing/selftests/net

[PATCH net-next v3 0/3] UDP GSO audit tests

Updates to UDP GSO selftests ot optionally stress test CMSG subsytem, and report the reliability and performance of both TX Timestamping and ZEROCOPY messages. Fred Klassen (3): net/udpgso_bench_tx: options to exercise TX CMSG net/udpgso_bench.sh add UDP GSO audit tests net/udpgso_bench.sh

[PATCH net v4] net/udp_gso: Allow TX timestamp with UDP GSO

tests as noted by Willem de Bruijn Moving tests from net to net-next v3: Update only relevant tx_flag bits as per Willem de Bruijn v4: Update comments and commit message as per Willem de Bruijn Fixes: ee80d1ebe5ba ("udp: add udp gso") Signed-off-by: Fred Klassen --- net/ip

Re: [PATCH net-next v2 1/3] net/udpgso_bench_tx: options to exercise TX CMSG

> On May 28, 2019, at 2:35 PM, Willem de Bruijn > wrote: >> -static void flush_zerocopy(int fd) >> +static void flush_cmsg(struct cmsghdr *cmsg) >> { >> - struct msghdr msg = {0};/* flush */ >> + switch (cmsg->cmsg_level) { >> + case SOL_SOCKET: >> + if (cm

[PATCH net-next v2 3/3] net/udpgso_bench.sh test fails on error

Ensure that failure on any individual test results in an overall failure of the test script. Signed-off-by: Fred Klassen --- tools/testing/selftests/net/udpgso_bench.sh | 33 + 1 file changed, 33 insertions(+) diff --git a/tools/testing/selftests/net/udpgso_bench.sh

[PATCH net-next v2 2/3] net/udpgso_bench.sh add UDP GSO audit tests

) ./udpgso_bench_tx: Unexpected number of Zerocopy completions:493706 expected493704 received Also reduce individual test time from 4 to 3 seconds so that overall test time does not increase significantly. Signed-off-by: Fred Klassen --- tools/testing/selftests/net/udpgso_bench.sh | 18

[PATCH net-next v2 1/3] net/udpgso_bench_tx: options to exercise TX CMSG

: Enhancements as per Willem de Bruijn - Updated control and buffer parameters for recvmsg - poll() parameter cleanup - fail on bad audit results - remove TOS options - improved reporting Signed-off-by: Fred Klassen --- tools/testing/selftests/net/udpgso_bench_tx.c | 324

[PATCH net-next v2 0/3] UDP GSO audit tests

Updates to UDP GSO selftests ot optionally stress test CMSG subsytem, and report the reliability and performance of both TX Timestamping and ZEROCOPY messages. Fred Klassen (3): net/udpgso_bench_tx: options to exercise TX CMSG net/udpgso_bench.sh add UDP GSO audit tests net/udpgso_bench.sh

[PATCH net-next v3 0/1] Allow TX timestamp with UDP GSO

Fixes an issue where TX Timestamps are not arriving on the error queue when UDP_SEGMENT CMSG type is combined with CMSG type SO_TIMESTAMPING. Fred Klassen (1): net/udp_gso: Allow TX timestamp with UDP GSO net/ipv4/udp_offload.c | 5 + 1 file changed, 5 insertions(+) -- 2.11.0

[PATCH net-next v3 1/1] net/udp_gso: Allow TX timestamp with UDP GSO

nly relevant tx_flag bits as per Willem de Bruijn Fixes: ee80d1ebe5ba ("udp: add udp gso") Signed-off-by: Fred Klassen --- net/ipv4/udp_offload.c | 5 + 1 file changed, 5 insertions(+) diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index 065334b41d57..de8e

Re: [PATCH net 4/4] net/udpgso_bench_tx: audit error queue

> On May 28, 2019, at 8:08 AM, Willem de Bruijn > wrote: > I will push up latest patches soon. I did some testing and discovered that only TCP audit tests failed. They failed much less often when enabling poll. Once in about 20 runs still failed. Therefore I commented out the TCP audit tes

Re: [PATCH net 4/4] net/udpgso_bench_tx: audit error queue

> On May 27, 2019, at 6:15 PM, Willem de Bruijn > wrote: >> I wanted to discuss whether or not to attach a buffer to the >> recvmsg(fd, &msg, MSG_ERRQUEUE). Without it, I have >> MSG_TRUNC errors in my msg_flags. Either I have to add >> a buffer, or ignore that error flag. > > Either sounds r

Re: [PATCH net 4/4] net/udpgso_bench_tx: audit error queue

> On May 27, 2019, at 2:46 PM, Willem de Bruijn > wrote: >> Also, I my v2 fix in net is still up for debate. In its current state, it >> meets my application’s requirements, but may not meet all of yours. > I gave more specific feedback on issues with it (referencing zerocopy > and IP_TOS, sa

Re: [PATCH net 4/4] net/udpgso_bench_tx: audit error queue

Willem, Thanks for spending so much time with me on this patch. I’m pretty new to this, so I know I am making lots of mistakes. I have been working on a v2 of the selftests in net-next, but want to review the layout of the report before I submit (see below). Also, I my v2 fix in net is still up f

[PATCH net v2 0/1] Allow TX timestamp with UDP GSO

Fixes an issue where TX Timestamps are not arriving on the error queue when UDP_SEGMENT CMSG type is combined with CMSG type SO_TIMESTAMPING. This is version 2 which moves the tests to net-next. Fred Klassen (1): net/udp_gso: Allow TX timestamp with UDP GSO net/ipv4/udp_offload.c | 4 1

[PATCH net v2 1/1] net/udp_gso: Allow TX timestamp with UDP GSO

to set SOL_IP/IP_TOS. ./udpgso_bench_tx -4ucPv -S 1472 -q 182 -l2 -D 172.16.120.18 poll timeout udp tx: 0 MB/s1 calls/s 1 msg/s This patch preserves tx_flags for the first UDP GSO segment. This mirrors the stack's behaviour for IPv4 fragments. Fixes: ee80d1ebe5ba ("udp: add

Re: [PATCH net 1/4] net/udp_gso: Allow TX timestamp with UDP GSO

> On May 23, 2019, at 2:59 PM, Willem de Bruijn > wrote:what exactly is the issue with IP_TOS? > > If I understand correctly, the issue here is that the new 'P' option > that polls on the error queue times out. This is unrelated to > specifying TOS bits? Without zerocopy or timestamps, no mes

Re: [PATCH net 1/4] net/udp_gso: Allow TX timestamp with UDP GSO

> On May 23, 2019, at 2:39 PM, Willem de Bruijn > wrote: > Zerocopy notification reference count is managed in skb_segment. That > should work. > I’m trying to understand the context of reference counting in skb_segment. I assume that there is an opportunity to optimize the count of outstan

Re: [PATCH net 1/4] net/udp_gso: Allow TX timestamp with UDP GSO

> On May 23, 2019, at 2:59 PM, Willem de Bruijn > wrote: > what exactly is the issue with IP_TOS? > > If I understand correctly, the issue here is that the new 'P' option > that polls on the error queue times out. This is unrelated to > specifying TOS bits? Without zerocopy or timestamps, no

Re: [PATCH net 1/4] net/udp_gso: Allow TX timestamp with UDP GSO

> On May 25, 2019, at 8:20 AM, Willem de Bruijn > wrote: > > On Fri, May 24, 2019 at 6:01 PM Fred Klassen wrote: >> >> >> >>> On May 24, 2019, at 12:29 PM, Willem de Bruijn >>> wrote: >>> >>> It is the last moment th

Re: [PATCH net 1/4] net/udp_gso: Allow TX timestamp with UDP GSO

> On May 24, 2019, at 12:29 PM, Willem de Bruijn > wrote: > > It is the last moment that a timestamp can be generated for the last > byte, I don't see how that is "neither the start nor the end of a GSO > packet”. My misunderstanding. I thought TCP did last segment timestamping, not last byt

Re: [PATCH net 1/4] net/udp_gso: Allow TX timestamp with UDP GSO

> Interesting. TCP timestamping takes the opposite choice and does > timestamp the last byte in the sendmsg request. > I have a difficult time with the philosophy of TX timestamping the last segment. The actual timestamp occurs just before the last segment is sent. This is neither the start nor

Re: [PATCH net 2/4] net/udpgso_bench_tx: options to exercise TX CMSG

> > To ensure that we do not regress, when adding options, please consider > (just a general suggestion, not a strong request for this patch set) > updating the kselftest to run a variant of the test with the new code > coverage. In this case, make the code pass/fail instead of only user > interpr

Re: [PATCH net 1/4] net/udp_gso: Allow TX timestamp with UDP GSO

> Thanks for the report. > > Zerocopy notification reference count is managed in skb_segment. That > should work. > > Support for timestamping with the new GSO feature is indeed an > oversight. The solution is similar to how TCP associates the timestamp > with the right segment in tcp_gso_tstamp.

Re: [PATCH net 4/4] net/udpgso_bench_tx: audit error queue

Willem, this is only my 2nd patch, and my last one was a one liner. I’ll try to work through this, but let me know if I am doing a rookie mistake (learning curve and all). > On May 23, 2019, at 2:56 PM, Willem de Bruijn > wrote: > > On Thu, May 23, 2019 at 5:11 PM Fred Kl

[PATCH net 2/4] net/udpgso_bench_tx: options to exercise TX CMSG

("selftests: udp gso benchmark") Signed-off-by: Fred Klassen --- tools/testing/selftests/net/udpgso_bench_tx.c | 290 -- 1 file changed, 273 insertions(+), 17 deletions(-) diff --git a/tools/testing/selftests/net/udpgso_bench_tx.c b/tools/testing/selftests/net/udpgso_

[PATCH net 4/4] net/udpgso_bench_tx: audit error queue

gs (10885/s) Tx Timestamps: received: 34046 errors: 0 Zerocopy acks: received: 54422 errors: 0 Fixes: 3a687bef148d ("selftests: udp gso benchmark") Signed-off-by: Fred Klassen --- tools/testing/selftests/net/udpgso_bench_tx.c | 152 +++--- 1 file

[PATCH net 3/4] net/udpgso_bench_tx: fix sendmmsg on unconnected socket

Fixes the following error if using both -m and -u options: # ./udpgso_bench -4um -D 172.16.120.189 ./udpgso_bench: sendmmsg: Destination address required Fixes: 3a687bef148d ("selftests: udp gso benchmark") Signed-off-by: Fred Klassen --- tools/testing/selftests/net/udpgso_

[PATCH net 0/4] Allow TX timestamp with UDP GSO

ZEROCOPY messages. Fred Klassen (4): net/udp_gso: Allow TX timestamp with UDP GSO net/udpgso_bench_tx: options to exercise TX CMSG net/udpgso_bench_tx: fix sendmmsg on unconnected socket net/udpgso_bench_tx: audit error queue net/ipv4/udp_offload.c| 4 + tools

[PATCH net 1/4] net/udp_gso: Allow TX timestamp with UDP GSO

to set SOL_IP/IP_TOS. ./udpgso_bench_tx -4ucPv -S 1472 -q 182 -l2 -D 172.16.120.18 poll timeout udp tx: 0 MB/s1 calls/s 1 msg/s This patch preserves tx_flags for the first UDP GSO segment. This mirrors the stack's behaviour for IPv4 fragments. Fixes: ee80d1ebe5ba ("udp: add

read and get back to me

sometimes in SPAM folder. Best regards. Mr. Ambrose Fred

[PATCH 3/4] PCI: pciehp: Remove unused macro definitions

From: Frederick Lawler Now that all uses for the ctrl_*() printk wrappers are removed from files and replaces with pci_*() or pr_*() printk wrappers, remove the unused macro definitions. In addition to that, remove the MY_NAME macro. Signed-off-by: Frederick Lawler --- drivers/pci/hotplug/pcie

[PATCH 1/4] PCI: Replace dev_*() printk wrappers with pci_*() printk wrappers

From: Frederick Lawler Replace remaining instances of dev_*() printk wrappers with pci_*() printk wrappers. No functional change intended. Signed-off-by: Frederick Lawler --- drivers/pci/pcie/aer.c| 13 ++--- drivers/pci/pcie/aer_inject.c | 4 ++-- drivers/pci/pcie/dpc.c

[PATCH 4/4] PCI/portdrv: Add dev_fmt() to port drivers

From: Frederick Lawler Add dev_fmt() to port drivers. Signed-off-by: Frederick Lawler --- drivers/pci/hotplug/pciehp_core.c | 3 +++ drivers/pci/hotplug/pciehp_ctrl.c | 2 ++ drivers/pci/hotplug/pciehp_hpc.c | 3 +++ drivers/pci/hotplug/pciehp_pci.c | 2 ++ drivers/pci/pcie/aer.c

[PATCH 0/4] PCI: Use PCIe service name in dmesg logs

From: Frederick Lawler In referrence to [1], PCIe services did not have unifrom logging via pci_*() printk wrappers. This patch series first replaces left over dev_*() calls for port services. Then, replaces all hotplug ctrl_*() calls with pci_*() to bring hotplug in line with the other services,

[PATCH 2/4] PCI: pciehp: Replace ctrl_*() with pci_*()

From: Frederick Lawler Hotplug useses custom ctrl_*() dev_*() printk wrappers for logging messages. To make hotplug conform to pci logging, replace uses of these wrappers with pci_*() printk wrappers. In addition, replace any printk() calls with pr_*() wrappers. Signed-off-by: Frederick Lawler

Re: [PATCH v2] ipmi: Prevent use-after-free in deliver_response

Correct, targeting 5.0. > On Jan 19, 2019, at 5:30 PM, Corey Minyard wrote: > > I assume you want this for 5.0., right?

[PATCH v2] ipmi: Prevent use-after-free in deliver_response

handle_new_recv_msgs+0x1ce/0x440 tasklet_action_common.isra.19+0xc4/0x250 __do_softirq+0x11f/0x51f Fixes: e86ee2d44b44 ("ipmi: Rework locking and shutdown for hot remove") Cc: sta...@vger.kernel.org Signed-off-by: Fred Klassen --- drivers/char/ipmi/ipmi_msghandler.c | 2 +- 1 file changed, 1 inser

PATCH] ipmi: Prevent use-after-free in deliver_response

/0x21d0 handle_new_recv_msgs+0x1ce/0x440 tasklet_action_common.isra.19+0xc4/0x250 __do_softirq+0x11f/0x51f Fixes: e86ee2d44b4 ("ipmi: Rework locking and shutdown for hot remove") Signed-off-by: Fred Klassen Cc: sta...@vger.kernel.org --- drivers/char/ipmi/ipmi_msghandler.c | 2 +- 1 fi

[PATCH] ipmi: Prevent use-after-free in deliver_response

handle_one_recv_msg+0x37a/0x21d0 handle_new_recv_msgs+0x1ce/0x440 tasklet_action_common.isra.19+0xc4/0x250 __do_softirq+0x11f/0x51f Fixes: e86ee2d44b4 ("ipmi: Rework locking and shutdown for hot remove") Signed-off-by: Fred Klassen --- drivers/char/ipmi/ipmi_msghandler.c | 2

i have been searching for you since you left our country

sometimes in SPAM folder. Best regards. Mr. Ambrose Fred --

CHANGE OF BENEFICIARY IT IS VERY URGENT

FROM: MR FRED WILSON BARCLAYS BANK PLC. 4 PERRY CLOSE LEKKI, LAGOS, NIGERIA. {barclaysbank...@gmail.com Attention: Beneficiary, CHANGE OF BENEFICIARY This is very urgent and an urgent attention is needed. In our office today, was a present of One Mr. John T. Kehoe of 1200 Fitch Way

Delivery Notification

and we look forward to hearing from you soon. If you have any question do NOT hesitate to email us on postecargou...@gmail.com Yours Faithfully, Anderson Fred Post Cargo Unit. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

I am looking forward to your prompt reply !!!

Dear Friend, I need your urgent attention for a business Proposal. Hope to hear from you for more details. Warmest regards Mr. Ambrose Fred

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

mitigation), such that sometimes the heavier Skylake+ mitigation would be applied on older CPUs. This is correct, just slower. I'm just suggesting this rather than keying on Family/Model/Stepping to avoid breaking virtual machine migration, et cetera. Thanks, Fred, sticking his neck out. On

Using very large multidimensional arrays to buffer IO/possibly used for the LM scheduler

I beleive that multidimensional arrays to a high power tied to a binary tree with a hash could help IO, at the cost of CPU power and memory. I would like this to be added to the BTRFS source. Here is an example.. before I start i just want to say I'm not that great at the Linux kernel, and I havent

Can I give you this trust

give you details and procedure when I recieve your reply.To commence this transaction, I require you to immediately indicate your interest by a return reply. I will be waiting for your response in a timely manner. Best Regard, Mr. FRED MARTINS

kdbus vs Plumber?

Plumber is the IPC system from Plan 9 from Bell Labs? It was written by Rob Pike. https://en.wikipedia.org/wiki/Plumber_%28program%29 How does kdbus compare against Plumber? Could Plumber be used instead? Is Plumber a better solution? Plumber together with 9P is also network transparent. Plumber

Re: [PATCH] ath9k_htc: check seq number instead of cmd id for timeout

Hi all, May I have an update on the patch status please? Thanks and regards, Fred On 13/3/2015 4:32 PM, Fred Chou wrote: > From: Fred Chou > > As the driver may send multiple wmi commands with identical cmd id, > it is more robust to check seq number for timeout instead. >

Re: [PATCH] ath9k_htc: check seq number instead of cmd id for timeout

On 15/03/2015 14:48, Oleksij Rempel wrote: > thank you for your patch. Looks good for me. Did you tested it? Yes. Working all right for two days. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH] ath9k_htc: check seq number instead of cmd id for timeout

From: Fred Chou As the driver may send multiple wmi commands with identical cmd id, it is more robust to check seq number for timeout instead. Signed-off-by: Fred Chou --- drivers/net/wireless/ath/ath9k/wmi.c | 12 ++-- drivers/net/wireless/ath/ath9k/wmi.h | 2 +- 2 files changed, 7

Re: [PATCH] ath9k_htc: avoid memcpy when downloading firmware

On 3/3/2015 2:00 PM, Eric Dumazet wrote: > On Tue, 2015-03-03 at 12:24 +0800, Fred Chou wrote: >> From: Fred Chou >> >> The temporary buffer to hold firmware data is not really needed, >> and memcpy can be avoided by using data pointer instead. >> >> Signe

[PATCH] ath9k_htc: avoid memcpy when downloading firmware

From: Fred Chou The temporary buffer to hold firmware data is not really needed, and memcpy can be avoided by using data pointer instead. Signed-off-by: Fred Chou --- drivers/net/wireless/ath/ath9k/hif_usb.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a

[PATCH] net: wireless: rt2x00: use helper to check capability/requirement

From: Fred Chou Use rt2x00_has_cap_flag macro to check rt2x00dev->cap_flags. Signed-off-by: Fred Chou --- drivers/net/wireless/rt2x00/rt2x00config.c | 4 ++-- drivers/net/wireless/rt2x00/rt2x00dev.c | 18 +- drivers/net/wireless/rt2x00/rt2x00firmware.c |

[PATCH] fs: fat: use MSDOS_SB macro to get msdos_sb_info

From: Fred Chou Use the MSDOS_SB macro to get msdos_sb_info, instead of coding it directly. Signed-off-by: Fred Chou --- fs/fat/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fat/inode.c b/fs/fat/inode.c index 1956dae..0f52d5f 100644 --- a/fs/fat/inode.c +++ b

[PATCH] staging: vt6655: remove unused function in mac.c

From: Fred Chou Removed the unused function MACvGetShortRetryLimit, which also fixed the following sparse warning: drivers/staging/vt6655/mac.c:162:6: warning: symbol 'MACvGetShortRetryLimit' was not declared. Should it be static? Signed-off-by: Fred Chou --- drivers/staging/vt

[PATCH] staging:lustre:lustre:ptlrpc: fix sparse warnings in lproc_ptlrpc.c

From: Fred Chou Fixed the below warning in sparse: drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c:184:6: warning: symbol 'ptlrpc_lprocfs_register' was not declared. Should it be static? Signed-off-by: Fred Chou --- drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c | 7

Re: [PATCH v3] staging: rtl8192u: fix sparse warnings

On 4/12/2014 4:30 PM, Sudip Mukherjee wrote: > On Thu, Dec 04, 2014 at 04:12:47PM +0800, Fred Chou wrote: >> >> >> On 4/12/2014 3:34 PM, Sudip Mukherjee wrote: >>> On Thu, Dec 04, 2014 at 10:50:43AM +0800, Fred Chou wrote: >>>> From: Fred Chou >&g

Re: [PATCH v3] staging: rtl8192u: fix sparse warnings

On 4/12/2014 3:34 PM, Sudip Mukherjee wrote: > On Thu, Dec 04, 2014 at 10:50:43AM +0800, Fred Chou wrote: >> From: Fred Chou >> >> Fixed the following warnings in sparse: >> >> drivers/staging/rtl8192u/r8192U_core.c:670:6: warning: >> symbol 'dum

[PATCH v3] staging: rtl8192u: fix sparse warnings

From: Fred Chou Fixed the following warnings in sparse: drivers/staging/rtl8192u/r8192U_core.c:670:6: warning: symbol 'dump_eprom' was not declared. Should it be static? drivers/staging/rtl8192u/r8192U_core.c:1489:5: warning: symbol 'ComputeTxTime&#x

[PATCH v2] staging: rt8192u: fix sparse warnings in r8192U_core.c

From: Fred Chou v2: alignment to match open parenthesis Fixed the following warnings in sparse: drivers/staging/rtl8192u/r8192U_core.c:670:6: warning: symbol 'dump_eprom' was not declared. Should it be static? drivers/staging/rtl8192u/r8192U_core.c:1489:

[PATCH] staging: rt8192u: fix sparse warnings in r8192U_core.c

From: Fred Chou Fixed the following warnings in sparse: drivers/staging/rtl8192u/r8192U_core.c:670:6: warning: symbol 'dump_eprom' was not declared. Should it be static? drivers/staging/rtl8192u/r8192U_core.c:1489:5: warning: symbol 'ComputeTxTime&#x

[PATCH] staging: rt8192u: fix sparse warnings in r8192U_core.c

From: Fred Fixed the following warnings in sparse: drivers/staging/rtl8192u/r8192U_core.c:670:6: warning: symbol 'dump_eprom' was not declared. Should it be static? drivers/staging/rtl8192u/r8192U_core.c:1489:5: warning: symbol 'ComputeTxTime&#x

[PATCH] staging: rt8192u: fix sparse warnings in r8192U_core.c

ed. Should it be static? Signed-off-by: Fred Chou --- drivers/staging/rtl8192u/r8192U_core.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c index 7640386..6b647ad 100644 ---

[PATCH] staging: rt8192u: fix sparse warnings in r8192U_core.c

ed. Should it be static? Signed-off-by: Fred Chou --- drivers/staging/rtl8192u/r8192U_core.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c index 7640386..6b647ad 100644 ---

[PATCH] vme: remove redundant else condition

The else condition is redundant after a return. Remove these redundant else conditions. Signed-off-by: Fred Chou --- drivers/staging/vme/devices/vme_pio2_gpio.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/staging/vme/devices/vme_pio2_gpio.c b

Re: [PATCH v3 1/2] Staging: comedi: addi-data: Fix long CamelCase function names

On Wednesday, March 12, 2014 01:06:27 AM Hartley Sweeten wrote: > On Tuesday, March 11, 2014 3:19 PM, Fred Akers wrote: > > This patch fixes a few function names that are very long and are > > not in the correct naming style > > > > Signed-off-by: Fred Akers >

Re: [PATCH] Staging: comedi: apci_1564: Fix long CamelCase function names

On Tuesday, March 11, 2014 02:31:07 PM Ian Abbott wrote: > On 2014-03-09 07:26, Fred Akers wrote: > > This patch fixes a few function names that are very long and are > > not in the correct naming style > > > > Signed-off-by: Fred Akers > > --- > &

[PATCH] Staging: comedi: apci_1564: Fix long CamelCase function names

This patch fixes a few function names that are very long and are not in the correct naming style Signed-off-by: Fred Akers --- .../comedi/drivers/addi-data/hwdrv_apci1564.c | 62 ++ drivers/staging/comedi/drivers/addi_apci_1564.c| 16 +++--- 2 files changed, 36

[PATCH v2 2/2] Staging: comedi: range: remove unnecessary sanity check

This check is unnecessary because range_table will always be initialized to range_unknown by comedi_device_postconfig() for drivers that do not initialize range_table or range_table_list Signed-off-by: Fred Akers --- drivers/staging/comedi/range.c | 4 1 file changed, 4 deletions(-) diff

[PATCH v2 1/2] Staging: comedi: range: tidy up comedi_check_chanlist()

Refactor this function to remove an extra indent level Signed-off-by: Fred Akers --- drivers/staging/comedi/range.c | 39 +++ 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/drivers/staging/comedi/range.c b/drivers/staging/comedi/range.c index

[PATCH] Staging: comedi: range: remove unnecessary sanity check

This check is unnecessary because range_table will always be initialized to range_unknown by comedi_device_postconfig() for drivers that do not initialize range_table or range_table_list Signed-off-by: Fred Akers --- Apply this after first patch drivers/staging/comedi/range.c | 4 1 file

[PATCH] Staging: comedi: range: tidy up comedi_check_chanlist()

Refactor this function to remove an extra indent level Signed-off-by: Fred Akers --- drivers/staging/comedi/range.c | 39 +++ 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/drivers/staging/comedi/range.c b/drivers/staging/comedi/range.c index

[tip:x86/cleanups] x86, boot: Fix warning due to undeclared strlen()

Commit-ID: 062fe8fe511e7f771ef1dc824eaf996ba50a694b Gitweb: http://git.kernel.org/tip/062fe8fe511e7f771ef1dc824eaf996ba50a694b Author: Fred Chen AuthorDate: Tue, 13 Aug 2013 11:13:00 -0700 Committer: H. Peter Anvin CommitDate: Tue, 13 Aug 2013 11:27:39 -0700 x86, boot: Fix warning due

[PATCH] strlen patch

Below is a patch that fixes sparse error "arch/x86/boot/string.c:119:8: warning: symbol 'strlen' was not declared." by declaring it in arch/x86/boot/boot.h. Signed-off-by: Fred Chen --- arch/x86/boot/boot.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff -

Re: Slow, persistent memory leak in 2.6.20

On 8/26/07, Denys Vlasenko <[EMAIL PROTECTED]> wrote: > On Sunday 26 August 2007 17:16, Fred Tyler wrote: > > So, I guess it worked? (I don't know what was supposed to happen, but > > memory usage dropped significantly when I did this.) > > If you can reclaim &q

Re: Slow, persistent memory leak in 2.6.20

On 8/26/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Aug 26 2007 12:16, Fred Tyler wrote: > >> Please rule out filesystem caches by issuing > >> sync; > >> echo 3 >/proc/sys/vm/drop_caches; > > > > > >So, I gue

Re: Slow, persistent memory leak in 2.6.20

On 8/26/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Aug 26 2007 12:16, Fred Tyler wrote: > >> Please rule out filesystem caches by issuing > >> sync; > >> echo 3 >/proc/sys/vm/drop_caches; > > > > >Ok, I did thi

Re: Slow, persistent memory leak in 2.6.20

On 8/26/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Aug 26 2007 11:51, Fred Tyler wrote: > >On 8/26/07, Fred Tyler <[EMAIL PROTECTED]> wrote: > >> I think I've come across a memory leak in 2.6.20. I've upgraded to the > >> latest 2.6.20.

Re: Slow, persistent memory leak in 2.6.20

On 8/26/07, Fred Tyler <[EMAIL PROTECTED]> wrote: > On 8/26/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > > > On Aug 26 2007 11:51, Fred Tyler wrote: > > >On 8/26/07, Fred Tyler <[EMAIL PROTECTED]> wrote: > > >> I think I'v

Re: Slow, persistent memory leak in 2.6.20

On 8/26/07, Fred Tyler <[EMAIL PROTECTED]> wrote: > I think I've come across a memory leak in 2.6.20. I've upgraded to the > latest 2.6.20.17, but it didn't seem to help. Sorry to keep replying to my own post, but further investigation suggests that the memory losses m

Re: Slow, persistent memory leak in 2.6.20

On 8/26/07, Fred Tyler <[EMAIL PROTECTED]> wrote: > I think I've come across a memory leak in 2.6.20. I've upgraded to the > latest 2.6.20.17, but it didn't seem to help. One more thing, I just found this message from July from someone seeing a similar problem: htt

Slow, persistent memory leak in 2.6.20

I think I've come across a memory leak in 2.6.20. I've upgraded to the latest 2.6.20.17, but it didn't seem to help. A little background: I saw something exactly like this many months ago with a 2.6.12 kernel. However, by 2.6.16.x the leak had apparently been fixed, so I didn't pursue it. I just a

Re: [2.6.21.1] SATA freeze

Robert Hancock wrote: Fred Moyer wrote: This appears to be a different problem. Something is issuing SMART-related commands (smartd or smartctl perhaps) which the drive seems to be reacting strangely to. It apparently completed the command but never raised DRQ to request any data being

Re: [2.6.21.1] SATA freeze

Robert Hancock wrote: Fred Moyer wrote: I just joined the list today so apologies if this email breaks any email client post threading. I have been seeing similar errors on two different systems. I applied Robert's sata_nv patch posted to the list on May 5th, and approved today by

Re: Re: [2.6.21.1] SATA freeze

Robert Hancock wrote: >Gerhard Mack wrote: >> On Wed, 9 May 2007, Jeff Garzik wrote: >>> Gerhard Mack wrote: May 9 14:51:35 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x180 action 0x2 frozen May 9 14:51:35 mgerhard kernel: ata1.00: cmd 35/00:00:80:6d:c8

[ACPI] Machine no longer enters C3 on 2.6.11-rc1-bk

in C3 apart from a bit right at the beginning, since 2.6.10. It has always been like that up to 2.6.6, became better from 2.6.7 (but had other problems with that). Fred P.S. I didn't check bus master activity. How do you do that? - To unsubscribe from this list: send the line "unsu

OT: ps source?

Sorry for asking on this mailing list. Can someone please tell me where to find the source code for the ps command? Thanks Fred __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ - To

PROBLEM: Kernel Oops 10% of diskless boots

0 PME- Capabilities: [f0] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x1 begin:vcard n:Feirtag;Fred tel;quoted-printable;work:505 - 294 - 7747=0D=0A tel;fax:505 - 275 - 1125 x-mozilla-html:TRUE url:http: