Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
Git
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins
 

Hurd Traffic #62 For 11 Oct 2000

By Zack Brown

Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?
Are you without a nice project and just dying to cut your teeth on an OS you can try to modify for your needs?
Are you finding it frustrating when everything works on minix? No more all-nighters to get a nifty program working?
Then this post might be just for you :-)
 
-- Linus Torvalds, 1991

Table Of Contents

Introduction

Thanks go to Thomas Viehmann for catching a grammar bug in Issue #61, Section #6  (29 Sep 2000: More Work On Installation CD) . The first sentence no verb. ;-) Thanks, Thomas!

Mailing List Stats For This Week

We looked at 115 posts in 446K.

There were 45 different contributors. 18 posted more than once. 23 posted last week too.

The top posters of the week were:

1. X Under The Hurd

24 Sep 2000 - 3 Oct 2000 (16 posts) Archive Link: "XFree86 3.3.6-10"

Topics: Apt

People: Marcus BrinkmannJordi Mallach

Marcus Brinkmann announced new X packages for 3.3.6, and gave instructions on how to get X running under the Hurd:

  1. get the latest Hurd package, hurd_20000921 This is currently in http://incoming.debian.org (NOT ftp) and will be moved to the archive tonight. So if it isn't there, chances are that it is in ftp.debian.org at the usual place.

    The new Hurd package comes with the kbd and mouse translator by Yasushi, so you don't need to get any other special files. (except maybe one). Everything is nicely packaged.

  2. Set up keyboard translator

    cd /dev
    ./MAKEDEV kbd

  3. Set up mouse translator

    This is a bit special. For me, with a serial mouse, this works:

    settrans /dev/mouse /hurd/mouse --device=com0 --protocol=microsoft

    (from memory). Read this document to find out:

    http://f77.nop.or.jp/doc/XFree86-3.3.3.1.html#theTable

  4. Install X packages.

    The X packages are in ftp://alpha.gnu.org/debian/dists/unstable/main/binary-hurd-i386/x11

    This source is apt-able, this means, you can use apt to get the packages on demand. You also need some font packages (binary-all) from ftp.debian.org. Simply add both resources to /etc/apt/sources.list and leave it to apt.

  5. Configure X.

    I recommend to use the Linux XF86Config and put it in /etc/X11/XF86Config and modify it. xf86setup may work, but there is a problem with the mouse (as the Hurd mouse setting is special).

    The only section where you need to be careful is the Pointer section. Only ONE variant works.

    Section "Pointer"
       Protocol "osmouse"
       Device "/dev/mouse/index.html"
    EndSection

    You can add Emulate3Buttons if you need it, of course. Everything else should work just as in linux.

  6. startx
  7. Bugs

    a) xterm and Ctrl-C/Ctrl-Z don't work correctly. You can't stop and suspend jobs correctly. That's bad! But there is a solution: Use rxvt :) rxvt is also in incoming and works. Somebody please debug the xterm problem and submit a patch! It can't be too hrd, but the xterm source is a real mess. Maybe the working rxvt code helps to debug this.

    b) pflocal gets many threads (~2000) and sucks up a lot of memory. Maybe there is some leak (port leak, memory leak). So over time, X might crash.

    Other random crashes can happen as well, but it is not too bad. In fact, it is quite stable for me.

    c) Because update-menu (menu is in incoming as well) doesn't work properly, our window managers don't have a fine Debian menu yet.

  8. Window Managers

    There is twm, which works. There is blackbox, which works. There is fvwm (v2) in incoming, which works as well.

  9. Other packages

    gtk is in incoming, the test programs work. The games I tested (xskat, xjump, xoids, xemeralda, xjewel) all work. xfishtank does not.

  10. Tasks

    Compile all packages using X!

Javier Viñuales Gutiérrez, Jordi Mallach and Prabhu Ramachandran all jumped up and down with joy, and Prabhu asked if there were any plans for X version 4. Marcus that he was going to take a break after the arduous struggles of X3, but added:

I do think that the working 3.3.6 will help, because you have actually something to stare at if you have problems. But I don't know what and how much has changed in X 4.0, and I always expect unexpected problems. (Not the problems themselve, but their existence).

Anyway, let's get some experience with 3.3.6 now first :) I have the 4.0 source code at home on CD, and will take a look at it. If I get a heart attack, I will scream loud enough for everyone to hear ;)

2. 'epic' Under The Hurd

30 Sep 2000 - 2 Oct 2000 (6 posts) Archive Link: "Trying to compile Epic"

People: Igor KhavkineAdam J. Farrell

Frederico S. Munoz was trying to get the 'epic' IRC client running under the Hurd (and was compiling natively as well), but had a few problems. First, he didn't understand what the MAXPATHLEN/PATHMAX values were used for. Also, even though he could compile the program successfully, it would give a general protection fault when run. Igor Khavkine replied:

Actually, at some point I've already gotten EPIC to compile under the Hurd. I don't have the changes anymore since it wasn't for myself but for someone who asked me for help on IRC. But I remember that the MAXPATHLEN issues. I didn't solve them properly since I only #defined it to be 4096 like in linux. A better way to handle it would be to use arbitrary length string operations provided by glibc. If you want an example check out my pmake patch at http://alcor.concordia.ca/~i_khavki/. The other issue was that EPIC tries to allocate an array of the size of the order of the maximum number of file descriptors on the system (you can query sysinfo(2) for that), on Hurd the number that you get is either INT_MAX or -1, so that's where the crash comes from. I didn't fix it properly either, just replaced it by some arbitrary large number.

Both of these problems are not strictly bugs (except under the Hurd) but more design decisions. So you have to dig around the code a bit, to see how you could fix it properly.

Adam J. Farrell completed Igor's history, saying, "Igor created a patch for Epic4-2000 a while back for myself. I believe the patch is available at ftp://ftp.unixpower.org/pub/hurd and ftp://ftp.stampede.org/incoming/skate111. I don't know, but if it is not email me back, and i'll email you the diff later." Frederico found and applied the patch, but discussion ended.

3. 'dummy' Interface For 'pfinet' (Edging Toward PPP)

30 Sep 2000 - 2 Oct 2000 (5 posts) Subject: "dummy interface for pfinet"

People: Marcus Brinkmann

Marcus Brinkmann implemented a 'dummy' interface for 'pfinet' and posted a patch for others to try. He gave a command to invoke it:

settrans /servers/socket/2 /hurd/pfinet -i dummy -a 192.168.0.1 -m 255.255.255.0 -g 192.168.0.2

and explained, "The dummy interface is the same as the dummy interface in linux: A bottomless pit. You don't get a single packet out of it, and everything you send to it is lost."

4. Hunting For A Memory Leak

2 Oct 2000 - 3 Oct 2000 (9 posts) Archive Link: "kernel panic/paging error"

People: Stephen R. GoreMarcus BrinkmannMark KettenisSteve Bowman

Ryan Tecco experienced paging errors followed by a kernel panic in a reproducible way. Marcus Brinkmann pegged this as an out of memory (OOM) condition and suggested adding more RAM or swap to the system. Stephen R. Gore and Frederico S. Munoz both said they saw the problem as well, even though they each had 128M RAM and 128M swap on their systems. Stephen speculated, "Seems that the process /hurd/pflocal has a memory leak. Very repeatable, most often triggered by apps that use advanced terminal functions (screen, vi, dselect for example). If not killed, the process will swap my box to death. OTOH, after I've killed such runaway processes once or twice, the problem doesn't usually occur again." Marcus also started seeing the same behavior, though he never had before, and gave his impressions:

pflocal get's suddenly nervous, and memory usage blows up, within a few seconds it sucks up all availalable RAM, and then swap (but slower). I saw a swap decrease of 4 MB every few seconds.

It's hard to get diagnostic info at this stage. I could run one "ps aux", which showed a memory usage of 66 MB, but after that, I could not get the number of ports nor the number of threads. I will try to get more info.

Maybe it is related to the pflocal changes without the corresponding new glibc, and updating glibc fixes that.

Mark Kettenis also reported seeing the same behavior, but had just ascribed it to problems with '/hurd/term/index.html' and pseudoterminals. To Marcus' idea that the problem was related to the recent 'pflocal' changes, he replied, "Probably not. It has been happening to me since before tinkering with pflocal." Steve Bowman posted a data point, "I caught it with a dozen M left in swap, had time to run ps, saw pflocal had all the memory (>120M), killed it and it restarted. It cleared about 65M from swap (I have 128M ram, 128M swap) which was still pretty high, but it stabilized there. I have debian package libc0.2 at version 2.1.3-10 and hurd at version 20000921," and asked if there were any particular things to do to get useful debugging information. Marcus replied:

Yes. First, find out about the thread and port usage:

ps -F hurd-long -x -a

Pipe the whole thing into a file for us.

Then, "portinfo PID | wc -l" shows the number of open ports, where PID is the pid of pflocal.

Then, find out what all those threads do:

gdb pflocal
...
set noninvasive on
attach PID
info threads

(again, PID being the pid of pflocal)

Is some thread stuck in some function? Are many threads stuck in the same function?

Debugging symbols would be useful, of course. I really have to upload a hurd with non-stripped object files...

Mark added, "Good suggestions. But before you do this, you might want to freeze the process by making it crash. `kill -ABRT PID' should do the job provided that the crash server has been set up right. Try `showtrans /servers/crash' to see if it is, and use `settrans /servers/crash /hurd/crash OPTIONS' to set it to do something sensible. I'm not sure what is the default, and you might want to make sure that orphaned processes are suspended. Try `/hurd/crash --help' to see what your options are." End of thread.

5. Moving Closer To A Temporary PPP Solution

4 Oct 2000 - 5 Oct 2000 (7 posts) Archive Link: "first shot at tunnel interface for pfinet"

People: Marcus BrinkmannDaniel E. Baumann

In frustration at the lack of development in this area after so much discussion, Marcus Brinkmann took a shot at a 'tunnel' interface for 'pfinet', and reported that he'd almost finished it. He explained, "What is missing? Well, there are some interface options for the linux kernel code we glue to, that need to be adjusted to get the correct input/output for a BSD tunnel interface. At least I think that is necessary. Currently, the interface emits ethernet frames, if I am not completely mistaken, and who knows what happens with the data you send to it. Apropos sending: Writing seems to be quite unstable, there are a couple of callbacks missing, and if you try to write with tools like "cat > /dev/tun0" you will get EIOIO and Resource lost and other inconvient stuff. However, normal write() seems to work fine. Mmmh."

Daniel E. Baumann asked if this was the direction PPP would take in the future, and Marcus replied, "No, it's a kludge to get it working, but a good kludge that holds some water." In his same post, Daniel asked, "Or would the libchannel stuff that Roland and others discussed previously be the ideal solution?" To which Marcus replied, "libchannel is still the way to go in the long term."

There was a bit more discussion, the conclusion being that PPP would not be too difficult to implement using this method.

6. Path Cleared For Userland PPP

5 Oct 2000 - 7 Oct 2000 (4 posts) Archive Link: "someone can port user space ppp now"

People: Marcus BrinkmannRoland McGrath

Marcus Brinkmann announced:

I have finished my work on the tunnel interface so far (There will be various updates to properly shut down the interface, etc, but the basic functionality is there) that I think someone can have a go at porting user space ppp. Don't count on me (I simply don't want to), I took a look at it, and it's quite ugly, because ppp does a lot of things we don't support, so you have to butcher to code a bit. See below for some tips.

Here is what you need: Current CVS Hurd, at least the pfinet directory. The patch from http://www.marcus-brinkmann.de/files/pfinet-tun-20001005.diff.gz

There are two options:

a. Porting netgraph and mpd, which uses netgraph.

b. Porting ppp.

You get ppp and mpd from ftp.whistle.com (/pub/archie/mpd etc) I don't know where netgraph is. I don't know which of those options will lead faster to a success.

Some initial porting tips: Define -D_BSD_SOURCE -DMAXHOSTNAMELEN=64 -DMAXPATHLEN=4096

In ppp, main(), remove the code that tries to close all file descriptors (our current libc binary still doesn't have Rolands patch to limit the announced number of available fds).

Use fsysopts to change the routing information and interface address. We currently don't support shutting down the interface, I think, but I think one can bring it up by starting with a pfinet that doesn't have one and adding it with fsysopts. You probably want to remove all fancy code in ppp that takes care of that, and only provide a small subset of all features.

I hope now that the hurd core stuff is done, some of the people who took interest in ppp by contributing to the design discussions (which have lead to the implementation of the tunnel device) are now making a serious (maybe collaborative) attempt to port the ppp stuff.

Specific questions about the porting should be asked on bug-hurd@gnu.org, not debian-hurd.

Roland McGrath said not to bother with 'netgraph' and 'mpd', adding, "When I suggested mpd, I didn't realize that netgraph was its only option." Of PPP, he said, "This is the one to use for now. I don't think there is too much to it." Later, Marcus announced:

I have now prepared a ppp source tar file which is hacked to compile the lot of the source files cleanly. This involved providing a few preprocessor symbols (MAXHOSTNAMELEN, MAXPATHLEN, _BSD_VA_LIST_) and messing around a bit with the header files (missing includes, etc). Instead changing every file, I put empty files if.h etc in net/, so that they can be found by "-I.". You can probably add stuff there for kludges.

http://www.marcus-brinkmann.de/files/ppp-hurd-000914.tar.gz

So, what is the status with this? The subdirectories libhack and pppctrl are unknown territory, maybe some stuff is needed from there, too. In ppp, of 49 necessary source files 41 compile.

* Real porting work has to be done here:

arp.c
bundle.c
iface.c
route.c

* Those are users and need very small fixes (missing preprocessor symbols):

command.c
ipcp.c
mp.c

* "Optional":

Fix up MD5 stuff in chap.c (we don't have <md5.h> and functions...) Add real code in tun.c when fsysopts can set --mtu.

There was no reply.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.