Older blog entries for jum (starting at number 14)

Well, as it turns out there is always just one more bug. After doing all that weird stuff to support Tru64 5.0 we just found one bug that appearently is in our Alpha port since ages. In some of the RPC calls we do transfer inode and device number as the ONC/RPC xdr type u_long, which is exactly 32 bits due to historic baggage. We did put the value in question into an u_long variable (there is no portable way to transfer dev_t or ino_t) and then did transfer that value. With the DEC specific ADVFS file system now device numbers (which are 32 bit signed ints) are negative, causing the u_long which is 64 bit as per argument passing to accumulate some extra 0xffffffff bits due to sign extension from the cast. The xdr_u_long routine now on Tru64 does check that the top 32 bits are indeed zero and fails the conversion, causing the whole RPC to fail mysteriously only on some file system types. Naturally our test machine had only UFS until recently...

After fiddling with the USB stuff in 2.2.18 a while I found a nice person who did email me the unusual devices entry for usb-storage.c. Now I can mount my digital camera as fat filesystem and I can directly call display vid:* to view my photos! Opposed to Windows the filesystem is mounted read only, but I can delete pictures using the camera so it is not a real problem.

I have got today a new camera, a Sony DSC-P1. This is a really nice gadget, although I do not understand why they deliver that with a ridicously small memory stick (4Mb). I will have to go out and get one or two larger ones. I have just tried the USB connection using the office Mac, and it works really easily. I will see how this works with the USB stuff I recently installed on my Toshiba Laptop under Linux.

After finally receiving Tue64 5.0a I have confirmed that the _RLD_LIST workaround from December 5th is not necessary any more. Instead of shipping this hack we will simply make 5.0a the minimum version supported. On the front of testing the CD016 stuff strange problems did pop up, for example the finite() function which is available about anywhere but Linux and DG/ UX. I also did hit a bug again from around 17 months ago that HP-UX 10 and 11 is not able to mmap files properly if the underlying file system is cdfs from a CD- ROM. Accordingly we must turn off mmap for HP-UX on all programs used for the install procedure. This one is really nasty, as you can install fine if the CD-ROM or master hard disk is mounted over NFS or copyied locally, only if really executed from cdfs the problem pops up. For each debugging step you must burn a new CD, and this takes a while.

After having that for some time on my to do list I today implemented dynamic DNS updates for our small internet access club, as some people have now flatrate ISDN/DSL access but still want to use the han.de domain. After looking a bit into how TSIG works I decided to simply create a dyn.han.de domain that allows updating from localhost and a web form to update that information via nsupdate. The TSIG stuff simply is too complicated for most users, a web page is easily filled out. And for the power users I did do a simple perl script using LWP::UserAgent to update the IP address automatically.

Today I did merge most of the stuff done on the updates branch to the main trunk in our CVS repository. As there are multiple updates branches depending upon product and subsystems (like shared libraries) this can get messy quickly and one can loose track what has been merged an what not. As the tags we are using are pretty regular I could probably scan for the tags on each file and if the file has any branches I could check if the BRANCHNAME_MERGED tag sits on the top level version of the branch.

The problem with all that is that I need to scan every file of the repository, which is quite a number of files. I think calling a program in a pipe to get the CVS/RCS info from the file does not scale well. I will probably need to dig into the RCS file format and scan that directly from the script.

After using Linux 2.2.18 for a while Markus did notice a Problem with the Linux NFS code, after creating a directory one cannot always create a file in the new directory. With certain older NFS servers (for example AIX 4.1.5) one will get an EPERM while attempting to create a file. The linux-kernel mailing list did help in a few hours: Trond did respond and recommended to set the define NFSD_BROKEN_UID to 1 in fs/nfs/dir.c, and that indeed fixed the problem. I did rebuild the RPM's with that compatibility define.

Adter spending half the day in getting educated about the Windows browsing mechanisms (yech!) I found out that the 2.2.18 kernel is out and did build new binary RPM's for our installation CD. I did also update the /pub/linux area of the web server.

On my Toshiba laptop 2.2.18 appears to work fine as well, I did take the opportunity to also update the IRDA and USB stuff. The IRDA stuff works with my Palm V with either a hotsync or connecting via ppp. I played with ptelnet, and I think that using telnet with a stylus and handwriting is rather cumbersome, I have no idea if this is useful at all. But it was rather neat to use two wireless links to the Internet, one IRDA to the Toshiba and then the Breezecom 802.11 PC card to the ethernet in the basement. I will need to check the USB stuff a bit more, I do not have any external USB devices at home currently.

I finished more updates for CD016 today, but for Tru64 we need to update the curses based programs as the curses library is not compatible any longer. I decided to go with the _RLD_LIST based hack done yesterday to avoid waiting for Compaq to release the real update. The web based hupd Roland is doing is progressing fine, we did fix the user agent strings for our URL I/O libbrary so we properly see what versions are used in our Apache logs. On the Mac client side the Unicode mapping for color names are the last item still missing, if this is done ES Admin can be packaged up as an update as well.

While doing some stress testing USB transactions on MacOS X I have found some deadlock situation where a simple device transaction would hang a process forever, not even kill -9 will terminate the process. Hot plugging the USB device affected does appear to resume the program with an error code, but there appears to be something confused afterwards as the shutdown hangs. I had to do a hard reset just before leaving work, waiting for the reboot just to shutdown the thing.

Besides managing what updates will go into CD016 for getting PDF Handshake 2.0 out not much programming did occur. On the DEC Unix front I have been able to get a hack working that fixes the recvmsg/sendmsg syscalls by pre-loading a shared object that redefines these calls using the _RLD_LIST environment variable. As the current patch kit does not fix the problem, we will probably have to live that hack for a while.