Linux-Development-Sys Digest #201, Volume #7 Thu, 16 Sep 99 13:14:08 EDT
Contents:
Re: porting unnamed structures (Mumit Khan)
Handlind Packet Queues (Fernando Ortega Bellosta)
implement ioctl on /proc ? (Themos Tsikas)
Re: unix98 pty's problems (Remco van den Berg)
knfs error using SUN client on sockets (Jan Wielemaker)
Linux without PC BIOS ("Roland Zitzke")
Re: UDMA vs IDE: performance comparison wanted (Jens Klaas)
discounted systems to Open source developers- UK ("bgiltrap")
Re: UDMA vs IDE: performance comparison wanted ([EMAIL PROTECTED])
Re: UDMA vs IDE: performance comparison wanted (Joseph H Allen)
mmap problems (Carsten Prinz)
Re: UDMA vs IDE: performance comparison wanted (Jens Klaas)
Re: UDMA vs IDE: performance comparison wanted (Joseph H Allen)
Re: UDMA vs IDE: performance comparison wanted (Mark Hahn)
Re: UDMA vs IDE: performance comparison wanted (Mark Hahn)
Re: help.. This should work but why doesn't it??? (write fnc in driver) (Julius
Longauer)
Re: GUI apps core dumping on printf's ("John Barry")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mumit Khan)
Subject: Re: porting unnamed structures
Date: 16 Sep 1999 07:11:43 GMT
In article <7rp0mm$rpt$[EMAIL PROTECTED]>,
Uwe Bonnes <[EMAIL PROTECTED]> wrote:
>Paul J Collins <[EMAIL PROTECTED]> wrote:
>:>>>>> "Michael" == Michael Minnick <[EMAIL PROTECTED]> writes:
>
>: --snip--
>: Michael> hello.c:4: warning: unnamed struct/union that defines no
>: Michael> instances hello.c: In function `main': hello.c:9:
>: Michael> structure has no member named `foo'
>: --snip--
>
>: AFAIR, that is an extension that Microsoft added. I cannot remember
>: the rationale for it. It is logical that it could exist, given that
>: C++ has anonymous unions (and I think they will be in the next C
>: standard, whatver that one is; I have forgotten the name).
>
>Hallo,
>
>as I understand it, cygwin/ecgs has patches to make ecgs understand those
>constructs. Look at http://www.cygnus.com/cygwin
Your understanding is incorrect, sorry.
Alastair Houghton submitted a patch a while back, and I've resubmitted
that with minor changes to gcc folks. There are still issues to be
worked out however, and I'm working on it (as soon as I can get some
free time).
This patch is included in my x86-win32 binaries; if you're interested,
see my posting to gcc (aka egcs) mailing list at
http://egcs.cygnus.com/ml/gcc/1999-08/msg01076.html for more info.
Regards,
Mumit
------------------------------
From: Fernando Ortega Bellosta <[EMAIL PROTECTED]>
Subject: Handlind Packet Queues
Date: Thu, 16 Sep 1999 11:27:17 +0200
I am working on a kernel module to modify the packet queues of the
devices, for example , I want to add new packets with different priorities
to the queue of the slip device.
I think each device has three queues.
dev->buffs[DEVNUMBUFFERS]
and I want to analyse the behaviour of the priorities queues under
cogestion circunstances.
My problem is that when I try to add new packets in my module, using
skb_queue_head();
the system fails, why??
I tried to make a clone of the sk_buff before queueing it but it does not
work.
Is it possible to do what I am trying to?
Can I modify this queues without corrupting them?
Do you know a better way to deal with this queues?
--
Fernando Ortega Bellosta
[EMAIL PROTECTED]
------------------------------
From: Themos Tsikas <[EMAIL PROTECTED]>
Subject: implement ioctl on /proc ?
Date: Thu, 16 Sep 1999 09:44:21 +0100
Hello
I would just like to know if anyone is planning on implementing ioctl
calls for the /proc filesystem like OSF1 and Solaris. So that we aren't
limited to doing "cat /proc/this/that" and parsing the ASCII.
Please e-mail any answers as well
------------------------------
From: [EMAIL PROTECTED] (Remco van den Berg)
Subject: Re: unix98 pty's problems
Date: 16 Sep 1999 09:46:33 GMT
On Wed, 15 Sep 1999 21:17:58 GMT, Juergen Heinzl wrote:
>
>>Any more programs?
>
>Yes. Mind I am not holding back; I've just no list either, so
>script for instance (util-linux). Try your talk and screen
>binaries too, if in use.
>
Is there a way to figure out if there are old pty's used by programs?
- Remco van den Berg
============================================================================
Philips Semiconductors B.V. tel:(+31 40 27)22031 fax:22764 Room: BE-345
mailto:[EMAIL PROTECTED] seri: rvdberg@nlsce1
home Email: [EMAIL PROTECTED] (non Philips related) ICQ: 47514668
============================================================================
Microsoft and Lotus Notes free. Don't send me any Microsoft attachments.
============================================================================
------------------------------
From: [EMAIL PROTECTED] (Jan Wielemaker)
Subject: knfs error using SUN client on sockets
Date: 16 Sep 1999 10:24:16 GMT
Hi,
I'm running a linux machine running linux-nfs-0.4.21 on top of 2.2.3
kernel with SUN compatibility compiled in. The client is a SPARC
system running Solaris 2.7 (aka SunOS 5.7 or Solaris 7.0 I think).
This all appears to work fine, except for one detail: if I try to
create a Unix-domain socket under Solaris on the filesystem mounted
from Linux. In this case, I get:
Cannot bind socket: Is a directory
Doing ls -l (both Solaris ls and GNU ls) on the socket on the solaris
machine yields:
% ls -l .xpce_emacs_server.solo
srwxr-xr-x 1 jan medewerk 0 Sep 16 12:17 .xpce_emacs_server.solo=
On the linux server I get exactly the same output. Doing the same if the
server is solaris too works just fine.
DejaNews yields nothing on this subject. Does anyone happen to know
whether this problem is known/fixed?
Regards --- Jan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jan Wielemaker Author of SWI-Prolog and the XPCE GUI library
SWI, University of Amsterdam http://www.swi.psy.uva.nl/projects/SWI-Prolog/
E-mail: [EMAIL PROTECTED] http://www.swi.psy.uva.nl/projects/xpce/
------------------------------
From: "Roland Zitzke" <[EMAIL PROTECTED]>
Subject: Linux without PC BIOS
Date: Thu, 16 Sep 1999 13:00:04 +0200
Hallo,
I want to run Linux on an embedded system which doesn't have a BIOS. Has
anyone ever written loader code that gets by without the BIOS code? Once the
system in in protected mode I would assume that no BIOS calles are performed
anymore. (it is not a P&P system with a P&P BIOS wrapper needed).
------------------------------
From: Jens Klaas <[EMAIL PROTECTED]>
Subject: Re: UDMA vs IDE: performance comparison wanted
Date: Thu, 16 Sep 1999 13:51:01 +0200
Philip Brown wrote:
> howdy,
>
> I'm wondering if anyone has a chart of IDE vs UDMA performance. Ideally,
> on the same machine using the same controller types, on the same
> RPM speed drives.
Hi,I made some test. At the time on different comuters, But the same
Harddisk. More test will follow after building a new kernel for the UDMA
Mode for the bad one.
To test the perfomance, I wrote a small program which write some Data with
different buttersizes to the disk.
- Pentium III 500/512kb, Siemens D1031 Board. (DMA Mode)
ide0: BM-DMA at 0xfcf0-0xfcf7, BIOS settings: hda:DMA, hdb:pio
hda: FUJITSU MPD3084AT, ATA DISK drive
hdb: TOSHIBA CD-ROM XM-6302B, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: FUJITSU MPD3084AT, 8063MB w/512kB Cache, CHS=16383/16/63, UDMA
hdb: ATAPI 32X CD-ROM drive, 256kB Cache
wrote 300 MB in 12 secounds, buffer = 1024 byte (25.000000 MB/sec)
wrote 300 MB in 17 secounds, buffer = 2048 byte (17.647059 MB/sec)
wrote 300 MB in 15 secounds, buffer = 3072 byte (20.000000 MB/sec)
wrote 300 MB in 13 secounds, buffer = 4096 byte (23.076923 MB/sec)
wrote 300 MB in 14 secounds, buffer = 5120 byte (21.428571 MB/sec)
wrote 300 MB in 16 secounds, buffer = 6144 byte (18.750000 MB/sec)
wrote 300 MB in 15 secounds, buffer = 7168 byte (20.000000 MB/sec)
wrote 300 MB in 14 secounds, buffer = 8192 byte (21.428571 MB/sec)
wrote 300 MB in 15 secounds, buffer = 9216 byte (20.000000 MB/sec)
wrote 300 MB in 15 secounds, buffer = 10240 byte (20.000000 MB/sec)
- 4Way-Pentium III 500/Xeon 512kb Siemens board D1111 (PIO Mode)
ide0: BM-DMA at 0x2440-0x2447, BIOS settings: hda:pio, hdb:pio
hda: FUJITSU MPD3084AT, ATA DISK drive
ide2: ports already in use, skipping probe
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: FUJITSU MPD3084AT, 8063MB w/512kB Cache, CHS=17475/15/63
wrote 300 MB in 62 secounds, buffer = 1024 byte (4.838710 MB/sec)
wrote 300 MB in 63 secounds, buffer = 2048 byte (4.761905 MB/sec)
wrote 300 MB in 65 secounds, buffer = 3072 byte (4.615385 MB/sec)
wrote 300 MB in 65 secounds, buffer = 4096 byte (4.615385 MB/sec)
wrote 300 MB in 65 secounds, buffer = 5120 byte (4.615385 MB/sec)
wrote 300 MB in 64 secounds, buffer = 6144 byte (4.687500 MB/sec)
wrote 300 MB in 64 secounds, buffer = 7168 byte (4.687500 MB/sec)
wrote 300 MB in 65 secounds, buffer = 8192 byte (4.615385 MB/sec)
wrote 300 MB in 65 secounds, buffer = 9216 byte (4.615385 MB/sec)
wrote 300 MB in 65 secounds, buffer = 10240 byte (4.615385 MB/sec)
cu
Jens Klaas (Nec Europe Ltd.)
------------------------------
From: "bgiltrap" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: discounted systems to Open source developers- UK
Date: Thu, 16 Sep 1999 13:09:43 +0100
We are about to launch a new distribution shortly and for a limited period
we have decided to offer discounted Linux Systems to Developers. If you are
interested please contact :
[EMAIL PROTECTED]
Bernard Giltrap, Ideas to Reality
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: UDMA vs IDE: performance comparison wanted
Date: Thu, 16 Sep 1999 12:20:36 GMT
In article <[EMAIL PROTECTED]>,
Robert Krawitz <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Philip Brown) writes:
>
> > I'm not interested in vague claims of "significant performance
> > increases". I'd like to see actual figures. Yes, I know it should be
> > faster. I'd like to know how MUCH faster.
8-9 Mb/sec PIO4 13-15 Mb/sec in UDMA33 Quantum CR8.4
CPU usage drops dramatically.
> Interestingly, I have to set the drive to a PIO mode in my BIOS for
> this to work at all, because otherwise the drive wants to go into
> UDMA/66, which doesn't work on my Abit BH6 mobo.
I've done a BIOS upgrade on my Shuttle HOT591P motherboard to
prevent it from turning udma66 on. The hardware can only do
udma33, but the bios didn't know that.
George Krajcsovits
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Joseph H Allen)
Subject: Re: UDMA vs IDE: performance comparison wanted
Date: Thu, 16 Sep 1999 12:48:14 GMT
In article <[EMAIL PROTECTED]>,
M van Oosterhout <[EMAIL PROTECTED]> wrote:
>Joseph H Allen wrote:
>> Did you change any 'hdparm' settings before you did this test?
>> Try: hdparm -m 16 -c 1 -A 1 -W 1 /dev/hda
>>
>> This makes sure that it's actually reading multiple sectors at a time, that
>> read ahead is enabled, that 32-bit mode is enabled, and that write caching
>> is enabled. This usually makes a huge difference if it had not been set,
>> since Linux makes pessimistic settings by default.
>
>I'm not sure wether this is common, but if I used hdparm to
>change *any* of the default settings, the disk just went slower.
>
>So it get's its maximum speed when it's marked for single-sector,
>16-bit I/O.
That's odd. For a WDC AC26400B, I get 2.37MB/sec without the hdparm
settings and 7.79MB/sec with them (>3 times faster). This is a cheap-o 6GB
drive, the kernel version is 2.0.30, and the CPU is K6-300, and the
motherboard is a very cheap MSI-5184. Perhaps something is different for
better hardware?
--
/* [EMAIL PROTECTED] (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
------------------------------
From: Carsten Prinz <[EMAIL PROTECTED]>
Subject: mmap problems
Date: Thu, 16 Sep 1999 15:14:49 +0200
Hi everybody,
I've a little problem writing data to a file using mmap.
The code:
/* begin mymap.c */
#include <sys/stat.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <stddef.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/types.h>
#define FNAME "test.dat"
int main() {
int fd;
void *dummy;
size_t len;
off_t off = 0;
char *data="Written with mmap";
if ((fd = open(FNAME,O_RDWR | O_CREAT,0666)) < 0) {
perror("open");
abort();
}
len = strlen(data);
if ((dummy = mmap(0,len,PROT_WRITE | PROT_READ ,MAP_PRIVATE ,fd,off))
== MAP_FAILED) {
perror("mmap");
abort();
}
memcpy(dummy,data,strlen(data));
if (msync(dummy,strlen(data),MS_SYNC) < 0) {
perror("msync");
abort();
}
printf("%s\n",dummy);
if (munmap(dummy,len) < 0) {
perror("munmap");
abort();
}
close(fd);
return 0;
}
/* end mymap.c */
The printf statement works fine, so dummy seems to have the right
content,
but the mapped file "test.dat" remains empty. The open,mmap,msync and
munmap calls return no error.
What's going wrong here ??
TIA,
carsten
--
=================================================================
Carsten Prinz [EMAIL PROTECTED]
public pgp key: http://www.uni-mainz.de/~cprinz/key_pgp.asc
pgp fingerprint: E2 CA ED 1A 82 34 6C 01 0E A6 33 BB F2 C6 F4 D0
=================================================================
------------------------------
From: Jens Klaas <[EMAIL PROTECTED]>
Subject: Re: UDMA vs IDE: performance comparison wanted
Date: Thu, 16 Sep 1999 15:55:16 +0200
Jens Klaas wrote:
> Philip Brown wrote:
>
> > howdy,
> >
> > I'm wondering if anyone has a chart of IDE vs UDMA performance. Ideally,
> > on the same machine using the same controller types, on the same
> > RPM speed drives.
More tests on our PIII/XEON computer.
The following cases:
- Bios mode PIO, Kernel supports PIO only.
write wrote 300 MB in 62 secounds, buffer = 1024 byte (4.838710 MB/sec)
write wrote 300 MB in 63 secounds, buffer = 2048 byte (4.761905 MB/sec)
write wrote 300 MB in 65 secounds, buffer = 3072 byte (4.615385 MB/sec)
write wrote 300 MB in 65 secounds, buffer = 4096 byte (4.615385 MB/sec)
write wrote 300 MB in 65 secounds, buffer = 5120 byte (4.615385 MB/sec)
write wrote 300 MB in 64 secounds, buffer = 6144 byte (4.687500 MB/sec)
write wrote 300 MB in 64 secounds, buffer = 7168 byte (4.687500 MB/sec)
write wrote 300 MB in 65 secounds, buffer = 8192 byte (4.615385 MB/sec)
write wrote 300 MB in 65 secounds, buffer = 9216 byte (4.615385 MB/sec)
write wrote 300 MB in 65 secounds, buffer = 10240 byte (4.615385 MB/sec)
- Bios mode PIO, Kernel supports DMA if available.
write wrote 300 MB in 19 secounds, buffer = 1024 byte (15.789474 MB/sec)
write wrote 300 MB in 21 secounds, buffer = 2048 byte (14.285714 MB/sec)
write wrote 300 MB in 19 secounds, buffer = 3072 byte (15.789474 MB/sec)
write wrote 300 MB in 19 secounds, buffer = 4096 byte (15.789474 MB/sec)
write wrote 300 MB in 19 secounds, buffer = 5120 byte (15.789474 MB/sec)
write wrote 300 MB in 19 secounds, buffer = 6144 byte (15.789474 MB/sec)
write wrote 300 MB in 21 secounds, buffer = 7168 byte (14.285714 MB/sec)
write wrote 300 MB in 19 secounds, buffer = 8192 byte (15.789474 MB/sec)
write wrote 300 MB in 23 secounds, buffer = 9216 byte (13.043478 MB/sec)
write wrote 300 MB in 19 secounds, buffer = 10240 byte (15.789474 MB/sec)
- Bios mode DMA, Kernel supports DMA if available.
write wrote 300 MB in 17 secounds, buffer = 1024 byte (17.647059 MB/sec)
write wrote 300 MB in 21 secounds, buffer = 2048 byte (14.285714 MB/sec)
write wrote 300 MB in 19 secounds, buffer = 3072 byte (15.789474 MB/sec)
write wrote 300 MB in 20 secounds, buffer = 4096 byte (15.000000 MB/sec)
write wrote 300 MB in 20 secounds, buffer = 5120 byte (15.000000 MB/sec)
write wrote 300 MB in 20 secounds, buffer = 6144 byte (15.000000 MB/sec)
write wrote 300 MB in 19 secounds, buffer = 7168 byte (15.789474 MB/sec)
write wrote 300 MB in 18 secounds, buffer = 8192 byte (16.666667 MB/sec)
write wrote 300 MB in 19 secounds, buffer = 9216 byte (15.789474 MB/sec)
write wrote 300 MB in 18 secounds, buffer = 10240 byte (16.666667 MB/sec)
cu Jens (NEC Europe Ltd.)
------------------------------
From: [EMAIL PROTECTED] (Joseph H Allen)
Subject: Re: UDMA vs IDE: performance comparison wanted
Date: Thu, 16 Sep 1999 14:23:00 GMT
In article <[EMAIL PROTECTED]>,
Jens Klaas <[EMAIL PROTECTED]> wrote:
>More tests on our PIII/XEON computer.
>The following cases:
>- Bios mode PIO, Kernel supports PIO only.
>write wrote 300 MB in 62 secounds, buffer = 1024 byte (4.838710 MB/sec)
>...
Have you done: hdparm -m 16 -c 1 -A 1 /dev/hda before doing the above PIO
test? I find it hard to beleive that a PIII/XEON can not get more than 4.84
MB/sec with program I/O (my cheap K6 gets 7.8 MB on a cheap hard drive).
--
/* [EMAIL PROTECTED] (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Subject: Re: UDMA vs IDE: performance comparison wanted
Date: 16 Sep 1999 14:50:16 GMT
> wrote 300 MB in 12 secounds, buffer = 1024 byte (25.000000 MB/sec)
unless you've only got around 100M of dram on that machine,
this test is meaningless, since you're measuring the buffer/page cache.
also, these are trivial-sized buffers; even 10K buffers are verging on
silly for modern machines, which routinely sustain 20 MB/s, since
you're also measuring 2K syscalls/second.
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Subject: Re: UDMA vs IDE: performance comparison wanted
Date: 16 Sep 1999 15:05:14 GMT
Joseph H Allen <[EMAIL PROTECTED]> wrote:
...
> since Linux makes pessimistic settings by default.
Linux mostly uses whatever you set in bios.
> I'm very surprised that the throughput would have doubled- even the simple
> programmed interface should be way faster than the actual data rate of the
> media (average bytes per track * disk RPM / 60).
PIO maxes out at either 13 or 16 MB/s, I forget which. that's sufficiently
slow that modern disks (which easily sustain 20 MB/s) can slip a rev.
------------------------------
From: Julius Longauer <[EMAIL PROTECTED]>
Subject: Re: help.. This should work but why doesn't it??? (write fnc in driver)
Date: Thu, 16 Sep 1999 17:36:22 +0200
Karlo Szabo wrote:
>
> > > This is defined at the begining of the module
> > >
>
> static char w_buf[BUF_SIZE]
>
> > > static char *write_buf;
> >
> > Shouldn't this be: char write_buf[SIZE]? You need to allocate space
> > for the stuff, not just a pointer.
>
> in the module_init()
>
> I have write_buf = &w_buf;
>
> so I guess the pointer points to the allocated array
>
> >
> > >
> > >
> > > static int z_write(struct inode *node,
> > > struct file *file,
> > > const char *buf,
> > > int count)
> > > {char *chbuf;
> > > unsigned long copy_size;
> > > chbuf = (char *) buf;
> > >
> > > copy_size = count;
> > > write_buf="pre copy from us"; /*This is not being overwritten by
> > > copy_from_user */
> >
> > I'm not sure why it doesn't get overwritten and blow up in your face,
> > but I know it's not nice to try to overwrite a constant. Should be:
> > strcpy(write_buf,"pre copy")'
> I'am not overwriting any constants.
> The above works fine, no explosions
>
The assignment works. After the assignment however write_buf doesn't
point to the origninally allocated memory but to the first element
of a static unnamed array of characters, which may be stored in
read-only memory and has only enough space for the string
"pre copy from us". This situation can result in protection faults
and buffer-overflows.
> [...]
Julius
------------------------------
From: "John Barry" <[EMAIL PROTECTED]>
Crossposted-To: comp.windows.x.kde,linux.dev.c-programming,comp.os.linux.x
Subject: Re: GUI apps core dumping on printf's
Date: Thu, 16 Sep 1999 11:51:30 -0000
Hello,
I am new to this thread, and you all may not be interested anymore, BUT...
>From using a Unix machine (g++ as compiler) I found that a newline (/n) char
works well with a carriage return (/r). Think about it, the /n drops the
text output a line but does not left justify it. The gui app could be
having trouble attempting to pad the left portion of the text off of the
left margin. Add a /r and see what happens (/n/r)
John
Dimi Shahbaz <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hello,
> When developing GUI apps (using KDE &qt) I like to put printf's and
> cout's in the code for debugging purposes. This use to work fine, and I
> saw the printf's in the app's parent terminal. Now, however, the GUI
> program core dumps if it printf's more than 1 newline to the parent
> terminal. Ie, if I printf("debug message\n something else\n"); I see
> the "debug message" printed ok, but the second line doesn't show up,
> and the program seg faults. The program also seg faults when I don't run
> it from a terminal but instead run it (by clicking on it) from a file
> manager in X.
>
> I have determined that 2 newlines is the problem because if I run the
> same program like such: `./program &> out` the program runs fine (ie,
> no seg fault).
>
> I don't have a clue what this could be, it is very strange. The machine
> in question is a pentium, with kde 1.1.1, and qt1.44. I don't think
> I have changed anything from when it worked to now. Any ideas? Has
> anyone run into this problem before?
>
> Thank in advance
> Dimi
>
>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
