Re: Http get commands return a bad results.

On Tue, 16 Nov 2004 14:04:51 -0800 (PST)
 Matthew Dillon <[e-mail]> wrote:

> :I report a problem that are caused yesterday cvsup, build and install.
> :Following things are just facts on my current system because I can't understand at
> :all why the problem occured. The new kernel has the problem that it's http get
> :command like wget(1) or fetch(1) sometimes return a bad result.
> :
> :Bad result example(file was downloaded by a new kernel's wget(1)):
> :$ gzip -cd gnotepad+-1.3.3.tar.gz | tar -xvf -
> 
>     Could you run an 'md5' checksum on the file when it is found to be
>     bad verses when it is found to be good ?  And then put the good and
>     the bad file up somewhere where I can fetch them so I can do a 
>     byte-by-byte comparison.

I've done to read that you were talking with walt about this problem. Probably you
don't need these now but I write my situation to be safe. My situation is same a
walt's situation, in fact file's md5s and sizes are almost different at any given
time.

And result examples with SACK(These are to be safe too):
http://wids.net/tmp/good_result_gnotepad+-1.3.3.tar.gz
http://wids.net/tmp/bad_result_gnotepad+-1.3.3.tar.gz
http://wids.net/tmp/bad_result2_gnotepad+-1.3.3.tar.gz
http://wids.net/tmp/bad_result3_gnotepad+-1.3.3.tar.gz


>     Also, in -CURRENT, try turning off sack and see if the problem still
>     occurs.
> 
>     sysctl net.inet.tcp.sack=0

I rebooted my system after I set this option("net.inet.tcp.sack=0") in the
/etc/sysctl.conf, and the problem partly resolved.

1. downloading from download.sourceforge.net to a file on NFS => bad
2. downloading from download.sourceforge.net to a file on DAS => bad
   (http://wids.net/tmp/without_sack_bad_result_gnotepad+-1.3.3.tar.gz)
3. downloading from ring.shibaura-it.ac.jp to a file on NFS => bad
4. downloading from ring.shibaura-it.ac.jp to a file on DAS => good
                               (I tested (2) and (4) three times, at least)

'download.sourceforge.net' are driven by Linux and 'ring.shibaura-it.ac.jp' are
driven by FreeBSD. I wonder why situation (2) do not change after SACK was disabled.
And I remembered, when I read 'Linux uses SACK too', my nfs server is 'Linux driven'
and the version is 2.4.19 for PPC. This thing is not related this problem if SACK is
related a tcp only. Or do I misunderstand ?


> :[diagnostic] cache_lock: blocked on 0xde0600b8 "getty"
> :[diagnostic] cache_lock: unblocked getty
> :[diagnostic] cache_lock: blocked on 0xde0600b8 "getty"
> :[diagnostic] cache_lock: unblocked getty
> 
>     These are not related.

OK, I relieved.


Regards.
-- 
H.Miyamoto (aka "Yuukis"). <[e-mail]>
           http://wids.net/ - Enjoy Your Computing ?