drivers/acpi/asus_acpi.c unsigned comparison

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)

index fec895a..9dfd0cd 100644
@@ -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
[email protected]

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

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!

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