Custom Query (28 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (13 - 15 of 28)

1 2 3 4 5 6 7 8 9 10
Ticket Owner Reporter Resolution Summary
#19 iskra iskra fixed CN control process leaks file descriptors
Description

When launching the fuse clients and such, the CN "control" process leaks internal file descriptors. It's not a big deal because the fuse client is trusted, and we do properly close the descriptors for the user app, but it would still be nice to fix. The problem is that system() call used to launch fuse and such does not make it easy. Should we implement a custom system()?

#18 zepto team iskra invalid Reading from /dev/tree kills CN kernel
Description

Communication over the tree is normally polling-based: we frequently read a status register from a user space process to see if any packets have arrived. This is wasteful in case of the "control" process running on the CNs, which is supposed to be a background process that sleeps when there's nothing to do. IBM added another mode of querying the tree network: one can call read() on the open file descriptor of /dev/tree. The call will block until a packet is available.

So much for the theory. In practice, when we forked off the ZeptoOS CNK from the IBM ION sources, that support was broken, and an attempt to read() from the fd results in a kernel crash if there are no packets waiting (i.e., if the calling process should be put to sleep).

IBM has since fixed the problem in the ION kernel. I diffed the tree driver sources between broken and fixed kernels and I seem to remember that they were identical, so the fix must be someplace else, but the complete kernel diff was large due to many unrelated changes. So the fix needs to be identified and ported from the current IBM ION to our ZeptoOS CN kernel.

#17 iskra iskra fixed MTU of TUN device can't be increased on IONs
Description

There seems to be a restriction on the ION kernel regarding the MTU size of the TUN device (which we use for IP forwarding). On the CN, we run a newer kernel (2.6.19.2) and can increase that MTU using "ifconfig" to 65535 without any problems. With the older (2.6.16-based) kernel on the IONs, the same ifconfig command returns an error, and we are stuck with the default 1500. As a result, the bandwidth of IP-forwarding infrastructure between CNs and IONs (over the tree network) is much lower than between two CNs (over torus). The ION kernel is capable of higher MTU values on other interfaces (eth0 uses 9000), and a quick diff of the TUN device source between CN and ION kernels does not turn up anything obvious, so it's a bit of a mystery what the problem is.

1 2 3 4 5 6 7 8 9 10
Note: See TracQuery for help on using queries.