Re: Major GNU/Hurd using report
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote: Tomasz Wegrzanowski [EMAIL PROTECTED] writes: 5) `which' and `type' don't work correctly They shows all commands to be /usr/bin/*, what is wrong, althru will work. Take /usr/bin off your $PATH then. And, as a side note, I understand that the reason this is there by default is that the hurd-i386 architecture is using the same source for the base-files packages as other architectures, and I rather suspect it's easier for the most part to arrange that the HURD works with at least some of the rest of Debian than to make the rest of Debian work with the HURD. -- Colin Watson [EMAIL PROTECTED]
Re: Major GNU/Hurd using report
On Thu, 04 May 2000 17:30:51 Tomasz Wegrzanowski wrote: 4) Is there any fatfs translator ? I am currently writing one! I volunteer to test it. Great. I hope to release it tonight. I got it working for FAT12 so far, and if I didn't do a stupid mistake, it should work on any other format as well. 5) `which' and `type' don't work correctly They shows all commands to be /usr/bin/*, what is wrong, althru will work. I don't know how these work, but probably by PATH and /usr/bin is before /bin in your path. I am not sure this can be considered as a bug. Should they display realpath instead? I don't think so. After all, the name is where it gets the binary from, and if it looks in /usr/bin before /bin, it will find everything there. 6) fsck says my Hurd partition is 10.2% non-contiguous It is 43% full, 920 MB total I don't know about this. Thanks, Marcus
Re: Major GNU/Hurd using report
On Fri, 05 May 2000 02:45:50 Colin Watson wrote: Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote: Tomasz Wegrzanowski [EMAIL PROTECTED] writes: 5) `which' and `type' don't work correctly They shows all commands to be /usr/bin/*, what is wrong, althru will work. Take /usr/bin off your $PATH then. And, as a side note, I understand that the reason this is there by default is that the hurd-i386 architecture is using the same source for the base-files packages as other architectures, but it is architecture: any, so we can get special hurd changes in. We have two possible sceanrios: Support /usr being a real directory by default, or doing it not. Scenario: Support for a real /usr: PATH=/usr/bin:/bin: (etc etc) LD_LIBRARY_PATH=/usr/lib:/X11R6/lib Scenario: No support for a real /usr: PATH=/bin: (etc etc) LD_LIBRARY_PATH=/X11R6/lib Note that currently we don't set LD_LIBRARY_PATH at all, but we should. This is something we need to change anyway, so I will file a bug report. But which of the two scenarios do we want? (BTW, it would be a nice idea to try to get X into / instead /X11R6. Then we could have: PATH=/bin:/local/bin (and no LD_LIBRARY_PATH)). Thanks, Marcus
Re: Major GNU/Hurd using report
On Fri, May 05, 2000 at 10:52:35AM +0200, Marcus Brinkmann wrote: On Fri, 05 May 2000 02:45:50 Colin Watson wrote: And, as a side note, I understand that the reason this is there by default is that the hurd-i386 architecture is using the same source for the base-files packages as other architectures, but it is architecture: any, so we can get special hurd changes in. We have two possible sceanrios: Support /usr being a real directory by default, or doing it not. Scenario: Support for a real /usr: PATH=/usr/bin:/bin: (etc etc) LD_LIBRARY_PATH=/usr/lib:/X11R6/lib Scenario: No support for a real /usr: PATH=/bin: (etc etc) LD_LIBRARY_PATH=/X11R6/lib Note that currently we don't set LD_LIBRARY_PATH at all, but we should. This is something we need to change anyway, so I will file a bug report. But which of the two scenarios do we want? My vote for second scenario /usr exists only due to histerical reasons (BTW, it would be a nice idea to try to get X into / instead /X11R6. Then we could have: PATH=/bin:/local/bin (and no LD_LIBRARY_PATH)). Actually it is possible to have X in / This is my Linux box configuration (but with symlink /X11R6-/ ) And if we move it before we have full X working there won't be any problems with backward compatibility
Re: Major GNU/Hurd using report
Tomasz Wegrzanowski [EMAIL PROTECTED] writes: Therefore there are these possibile reasons, why it is possible to r/w hardware ports : - I/O Permision Level is way too low but asm(pushfl) says IOPL=0 (kernel only) - user programs run in kernel space I hope not, no test was done This could be seen from the lowest bits of CS (as you probably know). - Mach gives default permision to every program to use all hardware ports No test was done yet Or: - the processors traps the instructions, but Mach's exception handler lets them run anyway Mach actually has code to detect the first access to a port and set the flag in the bitmap if permitted. Could you add some printfs in gnumach/i386/i386/io_emulate.c and gnumach/i386/i386at/iopl.c? showtrans says /servers/socket/2 is /hurd/pfinet -i=rfsd The = sign doesn't work with short options. Here the argument to -i is actually =rfsd which probably isn't a valid device. Translator died means the translator didn't even attach to the file first. Whenever this happens, you should try activating the translator manually with settrans -a so that you can see its error messages. settrans -a /servers/socket/2 /hurd/pfinet -i=rfsd IMHO there should be a way to see the error messages from translators even if the file system starts them. For root-owned files, perhaps the messages should go to syslog?
Re: Major GNU/Hurd using report
On Thu, May 04, 2000 at 01:39:50PM +0300, Kalle Olavi Niemitalo wrote: Tomasz Wegrzanowski [EMAIL PROTECTED] writes: Therefore there are these possibile reasons, why it is possible to r/w hardware ports : - I/O Permision Level is way too low but asm(pushfl) says IOPL=0 (kernel only) - user programs run in kernel space I hope not, no test was done This could be seen from the lowest bits of CS (as you probably know). %cs 0x03 = 0x03 fortunately user-space - Mach gives default permision to every program to use all hardware ports No test was done yet Or: - the processors traps the instructions, but Mach's exception handler lets them run anyway Any of these two, if Mach allows us to make userspace drivers is seems to be good idea to put all auxiliary device support (sound cards, graphics) in user-space. KGI is quite portable (some parts needs to be non-preemptive, possible on Mach ?) Probably IRQ manager should been put into Mach. It should also export pci configuration to user space (?) Mach actually has code to detect the first access to a port and set the flag in the bitmap if permitted. Could you add some printfs in gnumach/i386/i386/io_emulate.c and gnumach/i386/i386at/iopl.c? I'm not going to try compiling gnumach in *near* term. I had enough bad experience with Linux 2.3 and am affraid of kernels since then. BTW : what about idea, that mach should save all booting messages into RAM and then redirect it to userspace ? Due to lack of Linux-like scrool-back it is difficult to read them.
Re: Major GNU/Hurd using report
Tomasz Wegrzanowski [EMAIL PROTECTED] writes: 5) `which' and `type' don't work correctly They shows all commands to be /usr/bin/*, what is wrong, althru will work. Take /usr/bin off your $PATH then.
Re: Major GNU/Hurd using report
Tomasz Wegrzanowski [EMAIL PROTECTED] writes: KGI is quite portable (some parts needs to be non-preemptive, possible on Mach ?) Why does it require that -- does it work on multiprocessors at all? I'm not going to try compiling gnumach in *near* term. I had enough bad experience with Linux 2.3 and am affraid of kernels since then. Do you fear compiling it, or running the result? BTW : what about idea, that mach should save all booting messages into RAM and then redirect it to userspace ? That would be good.
Re: Major GNU/Hurd using report
On Thu, May 04, 2000 at 08:55:50PM +0300, Kalle Olavi Niemitalo wrote: Tomasz Wegrzanowski [EMAIL PROTECTED] writes: KGI is quite portable (some parts needs to be non-preemptive, possible on Mach ?) Why does it require that -- does it work on multiprocessors at all? It was said that KGI needs to block brige (?) when doing some operations (changing modes?) on some cards (dunno which ones) I'm not going to try compiling gnumach in *near* term. I had enough bad experience with Linux 2.3 and am affraid of kernels since then. Do you fear compiling it, or running the result? running the result
Major GNU/Hurd using report
1)
bash protests that it can't find `mesg' program when I log in
bash is of course right, because there is no `mesg' installed,
and `mesg' is part of sysvinit, so it's corrrect it's not installed
but why does bash need `mesg' ?
2)
Famous I/O problem
I tried to check if VGA registers are the only ones affected
And no, much more are affected
Here's CMOS reporting program
--- start ---
#include mach/machine/pio.h
int main() {
int i,j;
printf (CMOS content report\n\n);
for (i=0;i0x40;i++) {
outb (0x70,i);
j=inb (0x71);
printf (Cell $%d(0x%x) = %d\n,i,i,j);
}
printf (End of Report\n);
return 0;
}
--- end ---
outb is:
#define outb(port, val) \
({ asm volatile(outb %0, %1 : : a ((unsigned char)(val)) , d ((unsigned
short)(port))); })
Therefore there are these possibile reasons, why it is possible to r/w hardware
ports :
- I/O Permision Level is way too low
but asm(pushfl) says IOPL=0 (kernel only)
- user programs run in kernel space
I hope not, no test was done
- Mach gives default permision to every program to use all hardware ports
No test was done yet
3)
I have problems with networking
There is no eth, only loopback should be used
telnet doesn't work
tail of syslog - last two days (there was more than 1 run/day) :
--- start ---
May 2 12:40:41 localhost syslogd: restart
May 2 12:40:41 localhost inetd[29]: ftp/tcp: socket: Translator died
May 2 12:40:41 localhost inetd[29]: finger/tcp: socket: Translator died
May 2 12:40:41 localhost inetd[29]: telnet/tcp: socket: Translator died
May 2 12:40:41 localhost inetd[29]: shell/tcp: socket: Translator died
May 2 12:40:42 localhost inetd[29]: login/tcp: socket: Translator died
May 2 12:40:42 localhost inetd[29]: exec/tcp: socket: Translator died
May 2 12:40:42 localhost inetd[29]: ident/tcp: socket: Translator died
May 2 12:40:42 localhost inetd[29]: smtp/tcp: socket: Translator died
May 3 19:04:21 localhost syslogd: restart
May 3 19:04:20 localhost inetd[29]: ftp/tcp: socket: Translator died
May 3 19:04:21 localhost inetd[29]: finger/tcp: socket: Translator died
May 3 19:04:21 localhost inetd[29]: telnet/tcp: socket: Translator died
May 3 19:04:21 localhost inetd[29]: shell/tcp: socket: Translator died
May 3 19:04:21 localhost inetd[29]: login/tcp: socket: Translator died
May 3 19:04:21 localhost inetd[29]: exec/tcp: socket: Translator died
May 3 19:04:21 localhost inetd[29]: ident/tcp: socket: Translator died
May 3 19:04:21 localhost inetd[29]: smtp/tcp: socket: Translator died
--- end ---
Every time I `ls -l /servers/socket'
It prints :
`2 - translator died'
(then normal list)
mc says : `file 2 exists but can't be stated'
showtrans says /servers/socket/2 is /hurd/pfinet -i=rfsd
4)
Is there any fatfs translator ?
Re: Major GNU/Hurd using report
On Wed, May 03, 2000 at 08:35:19PM +0200, Tomasz Wegrzanowski wrote: but why does bash need `mesg' ? It's part of your login script (/root/.profile) 3) I have problems with networking There is no eth, only loopback should be used showtrans says /servers/socket/2 is /hurd/pfinet -i=rfsd What shall rfsd be? If this option is not recognised, the translator will die. Try with /hurd/pfinet -i rfsd at the command line and see if it complains. Try without this option. settrans /servers/socket/2 /hurd/pfinet 4) Is there any fatfs translator ? I am currently writing one! It can already list the root directory and stat some files, however, it is hopelessly buggy and no files can be read (I/O error). However, I did only work for a couple of hours on it, so there is hope. I will make the source public in a couple of days, so people can join me. (Need to clear it up before this, and attach proper copyright notices). I only aim at read-only without long file names. Long file names might follow, but I will not be able to implement write support in the near future. However, FAT12/16/32 will be supported. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
