[RESEND] [PATCH] drivers/acpi/asus_acpi.c unsigned comparison

[RESEND] [PATCH] drivers/acpi/asus_acpi.c unsigned comparison

[Gabriel A. Devenyi]

It helps if I attach the patch.

proc_write_brn, and proc_write_disp both use a parameter "count" to store the result from parse_arg.
The return of parse_arg is an int, but count is declared as an unsigned int, and later checked versus zero,
which is meaningless. This patch fixes the declaration of count in both functions.

Thanks to LinuxICC (http://linuxicc.sf.net)

Signed-off-by: Gabriel A. Devenyi <ace@staticwave.ca>

diff --git a/drivers/acpi/asus_acpi.c b/drivers/acpi/asus_acpi.c
index fec895a..9dfd0cd 100644
--- a/drivers/acpi/asus_acpi.c
+++ b/drivers/acpi/asus_acpi.c
@@ -748,7 +748,7 @@ proc_read_brn(char *page, char **start, 
 
 static int
 proc_write_brn(struct file *file, const char __user * buffer,
-	       unsigned long count, void *data)
+	       long count, void *data)
 {
 	int value;
 
@@ -798,7 +798,7 @@ proc_read_disp(char *page, char **start,
  */
 static int
 proc_write_disp(struct file *file, const char __user * buffer,
-		unsigned long count, void *data)
+		long count, void *data)
 {
 	int value;
 


-- 
Gabriel A. Devenyi
ace@staticwave.ca

Re: [RESEND] [PATCH] drivers/acpi/asus_acpi.c unsigned comparison

[Bjorn Helgaas]

On Saturday 12 November 2005 2:16 pm, Gabriel A. Devenyi wrote:
> It helps if I attach the patch.

And send it to the right places (copied, from MAINTAINERS).

> proc_write_brn, and proc_write_disp both use a parameter "count" to store the result from parse_arg.
> The return of parse_arg is an int, but count is declared as an unsigned int, and later checked versus zero,
> which is meaningless. This patch fixes the declaration of count in both functions.
> 
> Thanks to LinuxICC (http://linuxicc.sf.net)
> 
> Signed-off-by: Gabriel A. Devenyi <ace@staticwave.ca>
> 
> diff --git a/drivers/acpi/asus_acpi.c b/drivers/acpi/asus_acpi.c
> index fec895a..9dfd0cd 100644
> --- a/drivers/acpi/asus_acpi.c
> +++ b/drivers/acpi/asus_acpi.c
> @@ -748,7 +748,7 @@ proc_read_brn(char *page, char **start, 
>  
>  static int
>  proc_write_brn(struct file *file, const char __user * buffer,
> -	       unsigned long count, void *data)
> +	       long count, void *data)
>  {
>  	int value;
>  
> @@ -798,7 +798,7 @@ proc_read_disp(char *page, char **start,
>   */
>  static int
>  proc_write_disp(struct file *file, const char __user * buffer,
> -		unsigned long count, void *data)
> +		long count, void *data)
>  {
>  	int value;
>  
> 
> 
> -- 
> Gabriel A. Devenyi
> ace@staticwave.ca
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

ICMP Ping being lost between kernel and the ping program.

[Jesse Gordon]

Greetings. This is my first post.

I'm having a weird intermittent problem with ping.

I'm pinging the WAN port of a cheap home DSL firewall (d-link di-604) and 
sometimes the ping program fails to get a response,
but if I run tcpdump I can see that the response is indeed coming back.

arping on the target IP always works.

We're a small wireless ISP with 40ish customers -- each of whom has a cheap 
dlink router at their home. We ping each of them regularly to be notified of 
a wireless loss of connection.
(The wireless is Trango running at 5.x Ghz or ~900Mhz -- not 802.11) and all 
the wireless and switches are just ethernet bridges -- so it's a flat 
network with no ip based routing.

Two different dlink routers cause this problem but not necisarly at the same 
time.

Two different Linux computers exhibit this problem, although again, not 
always at the same time. One seems to be more picky -- sometimes just the 
picky one has a problem, other times they both have the problem.

Also, I have not yet noticed this problem while pinging from a windows 
computer.

Picky one:Linux 2.4.26
Less picky one: Linux 2.6.11.11 SMP

Anyhow, I don't know whether the dlinks are sometimes sending out sligly 
malformed packets, whether they are getting slightly damaged over the 
wireless network,
or whether Linux [the kernel] is having a problem, or if the ping program is 
having the problem. The facts just don't make sense for any of those.

I'll be glad to do all the normal stuff -- upgraded to latest kernel, (I did 
try upgrading to latest ping not too long ago no help - can try again),  if 
anyone thinks that'll help me solve the mystery.
I can even capture the text description of or the raw contents of packets 
with tcpdump or maybe ethereal, if that will help.

I did one time capture with ethereal a packet when ping was working, then a 
packet when it wasn't and compared them side by side in two ethereal 
instances -- and aside from the fields that should have been different, 
everything looked the same.

Thanks! 

Re: ICMP Ping being lost between kernel and the ping program. (Solved!)

[Jesse Gordon]

----- Original Message ----- 
"Jesse Gordon" <jesseg@nikola.com> wrote:

>Subject: ICMP Ping being lost between kernel and the ping program.
>
> Greetings. This is my first post.
>
> I'm having a weird intermittent problem with ping.
>
> I'm pinging the WAN port of a cheap home DSL firewall (d-link di-604) and 
> sometimes the ping program fails to get a response,
> but if I run tcpdump I can see that the response is indeed coming back.
> .. snip ..
> -Jesse

Solved.

The Dlink firewalls were responding with stale ICMP Identifier when pinged a 
second time, and the ping program was ignoring the responses which had a 
stale Identifier.

The windows box always works because it always uses the same number for 
Identifier. Ugh.

Thanks!

-Jesse