An outside HP service provides open source packages compiled to run on HP-UX systems. Our group within HP is currently moving to git with the majority of the git usage on linux systems. However, some older work still needs to be done on HP-UX systems and will require a working git set of tools. The current set of git tools works properly except for accessing gitolite, where ssh access and support is used. When trying to "clone" a gitolite hosted repo over ssh, the HP-UX git session fails with a core dump and "SIGBUS" error. I went through updating the HP-UX system with all the latest patches and was unable to alter the response in any way. After trying many options it became clear that the problem was inside git. I used wdb/gdb and tusc, where I tracked the failure down to a call to "recv_sideband" in sideband.c. It cores when the call is made. The calling process is "sideband_demux" in builtin/fetch-pack.c. "tusc" output showed a "pipe" of size 8192 being used prior to the core. I believe that git "forks" off a "ssh user@hostanme upload-pack 'repo_name'" that is "piped" back to the git stream process. In looking at the code, "sideband.h" defines "LARGE_PACKET_MAX 65520" and is related to the passed flag "side-band-64k" as discussed in git document pack-protocol.txt. The current default usage seems to be 64K transfers, yet if we check the "include/limits.h" of HP-UX we see a "PIPE_BUF" set to 8192. Along with the tusc indication of 8K pipe size, I suspect that HP-UX is coring due to git trying to use a 64K pipe when 8K is max. I solved the probem for now, by changing the file sideband.h to use "LARGE_PACKET_MAX 8208". If you use 8192 or less, you get a failure of too small size in "packet_read_line". So I added 16 bytes to 8192 to get the 8208 value. I noticed the previous value and some comments indicating an 8 to 10 byte overhead was needed and thus a few bytes more is needed in this define. I suspect the correct process would be making the HP-UX git use/send "side-band" and not "side-band-64k" in the get packet protocol, but I was unable to find out how to do that. The pack-protocol.txt discussion completely ignores this topic and how to handle clients with smaller abilities than servers. It appeared to me that the server set the transfer size and the client is just suppose to accept it. Under HPUX as a client, that is not an option, as it has a 8K max limit. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html