Re: NetBSD 10 and unreliable git
Hi, I think the situation is a little more complex and there may be some network card bug. Below my reasoning. Martin Husemann wrote: > I have never seen that (neither on 10.0 nor on -current). It is very > hard to tell what causes the errors for you. Two potential reasons > would be network issues (e.g. a bug in the driver for the network device > you are using) or the limit of simultaneous open files. - on core i3 latop, amd64, I had repeated several times on different WiFis... repeatable issue (checkout of gecko git). Attached wired and it worked. This points to be a network related issue, not open file or others. - on a vintage T43 with Pentium Mobile and troublesome iwi network card... the operation completed the first time plain over WiFi! And this system has half of the half performance of the above one... Riccardo
Re: NetBSD 10 and unreliable git
Hi Martin and Aryabhata,
network is probably the issue. I was around this weekend and used
wireless in two different places, the connection was good. I know both
places and used them often with different computers (parent's house,
girlfriend home.. not some hotel or airport).
However, at my home today I launched on both repositories via wired
ethernet and it worked.
Martin Husemann wrote:
> I have never seen that (neither on 10.0 nor on -current). It is very
> hard to tell what causes the errors for you. Two potential reasons
> would be network issues (e.g. a bug in the driver for the network device
> you are using) or the limit of simultaneous open files.
I suppose network issues. Since cloning the same repository and updating
the other - both failed before also with reboots - now worked. I hope
git is deterministic.
Now that I write, I remember having seen this error on one of my old
SparcStations. There, just reuissing the command helped. It was however
on a much smaller repository.
>
> If you are using /bin/sh (or bash) please tell us the output of "ulimit -a"
> [or for {t}csh: "limit").
sure:
sphere$ ulimit -a
time (-t seconds)unlimited
file (-f blocks )unlimited
data (-d kbytes ) 262144
stack (-s kbytes ) 4096
coredump (-c blocks )unlimited
memory(-m kbytes ) 7877324
locked memory (-l kbytes ) 2625774
thread(-r threads) 3991
process (-p processes ) 1024
nofiles (-n descriptors) 1024
vmemory (-v kbytes )unlimited
sbsize(-b bytes )unlimited
> What network device are you using? Can you show the relevant part of
> /var/run/dmesg.boot? Also the output of ifconfig for the device (sometimes
> checksum offload breaks things).
[ 1.048313] ral0 at pci3 dev 0 function 0: Ralink Technologies
RT3090 802.11b/g/n (rev. 0x00)
[ 1.048313] ral0: interrupting at ioapic0 pin 19
[ 1.048313] ral0: 802.11 address 70:f3:95:e2:36:11
[ 1.048313] ral0: MAC/BBP RT3090 (rev 0x3213), RF RT3020 (MIMO 1T1R)
Ifconfig in a non-connected status says:
ral0: flags=0x8802 mtu 1500
ssid ""
powersave off
address: 70:f3:95:e2:36:11
media: IEEE802.11 autoselect
status: no network
Do I need to connect?
Riccardo
Re: NetBSD 10 and unreliable git
On Mon, May 06, 2024 at 12:51:19PM +, Riccardo Mottola wrote:
> I'just doing a git clone or a git pull... so don't blame "me".
> At most git.. or its NetBSD compilation.
I have never seen that (neither on 10.0 nor on -current). It is very
hard to tell what causes the errors for you. Two potential reasons
would be network issues (e.g. a bug in the driver for the network device
you are using) or the limit of simultaneous open files.
If you are using /bin/sh (or bash) please tell us the output of "ulimit -a"
[or for {t}csh: "limit").
What network device are you using? Can you show the relevant part of
/var/run/dmesg.boot? Also the output of ifconfig for the device (sometimes
checksum offload breaks things).
Martin
Re: NetBSD 10 and unreliable git
Hi, Lucifer wrote: > you guys are using too many resources... I'just doing a git clone or a git pull... so don't blame "me". At most git.. or its NetBSD compilation. I am able to perform the same actions on the same repository on slower or less performing systems with other OSs though. Riccardo
Re: NetBSD 10 and unreliable git
It seems like you're encountering network-related issues while updating large Git repositories over WiFi. The error message "RPC failed; curl 92 HTTP/2 stream 7 was not closed cleanly: CANCEL (err 8)" indicates a problem with the network connection during the fetch operation. Here are a few things you can try to resolve this issue: 1 Check Network Stability: Ensure that your WiFi connection is stable and has a strong signal. You might want to try connecting via a wired Ethernet connection if possible, to rule out any WiFi-related issues. 2. Update Git and Dependencies: Make sure you have the latest version of Git installed. Additionally, check if there are any updates for related dependencies or libraries that Git relies on. 3. Increase Timeout Settings: You can try increasing the timeout settings for Git operations. For example, you can set a higher timeout value using `git config --global http.lowSpeedLimit 5000` (adjust the value as needed). 4 .Use SSH Protocol: Instead of HTTPS, consider using the SSH protocol for Git operations. This can sometimes provide a more stable connection. 5. Check Firewall and Proxy Settings: Ensure that there are no firewall or proxy settings interfering with your Git operations. Or You can force git using http version 1.1 git config --global http.version HTTP/1.1 On Fri, 3 May, 2024, 11:50 pm Riccardo Mottola, wrote: > Hi, > > I'm updating fairly big git repositories (e.g. mozilla and similar) and > continue getting these errors. I am over a fast WiFi. > > e$ git pull > remote: Enumerating objects: 4822, done. > remote: Counting objects: 100% (4822/4822), done. > remote: Compressing objects: 100% (1027/1027), done. > error: RPC failed; curl 92 HTTP/2 stream 7 was not closed cleanly: > CANCEL (err 8) > error: 5970 bytes of body are still expected > fetch-pack: unexpected disconnect while reading sideband packet > fatal: early EOF > fatal: fetch-pack: invalid index-pack output > > I can insist as much as I want, different byte count expected, but I am > unable to finish the operation. Being github, it is a decently reliable > server... and on other systems I don't have this issue. > I don't remember having many issues with 9.3, but maybe it is a mix of > network and kernel. > > Riccardo >
NetBSD 10 and unreliable git
Hi, I'm updating fairly big git repositories (e.g. mozilla and similar) and continue getting these errors. I am over a fast WiFi. e$ git pull remote: Enumerating objects: 4822, done. remote: Counting objects: 100% (4822/4822), done. remote: Compressing objects: 100% (1027/1027), done. error: RPC failed; curl 92 HTTP/2 stream 7 was not closed cleanly: CANCEL (err 8) error: 5970 bytes of body are still expected fetch-pack: unexpected disconnect while reading sideband packet fatal: early EOF fatal: fetch-pack: invalid index-pack output I can insist as much as I want, different byte count expected, but I am unable to finish the operation. Being github, it is a decently reliable server... and on other systems I don't have this issue. I don't remember having many issues with 9.3, but maybe it is a mix of network and kernel. Riccardo
