Linux-Development-Sys Digest #230, Volume #6 Thu, 7 Jan 99 06:14:07 EST
Contents:
Re: "soft" power button and linux (Ryan R. Henry)
Re: reboot problem with adaptec 2940uw (aic7881rev1) (Joop Marijne)
Re: disheartened gnome developer (Navindra Umanee)
Re: blocksize / file write speed anomaly (Stefaan A Eeckels)
Re: blocksize / file write speed anomaly (Bernd Strieder)
Re: silly question - Troll alert (Stefaan A Eeckels)
Re: Registry for Linux - Bad idea (George MacDonald)
Re: GUI, The Next Generation (Mike McDonald)
Re: blocksize / file write speed anomaly (Stefaan A Eeckels)
Re: Kernel v2.2 (Piniek (aka Piotr Ingling))
Re: WDM Emulator, anyone? (SONE Takeshi)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Ryan R. Henry)
Crossposted-To: comp.os.linux.hardware
Subject: Re: "soft" power button and linux
Date: 06 Jan 1999 14:24:02 -0500
Hmm...I haven't seen anything like that, except maybe on a Mac, but it's been a while
since I've seen one of those, either (my school uses Sun machines :). You could
unplug the button from the motherboard and make an adapter to plug it into a serial
port or something similar. From there it would be pretty easy.
Ryan Henry
---
Wrong on most accounts. const Foo *foo; and Foo const *foo; mean the same: foo
being a pointer to const Foo. const Foo const *foo; would mean the same but is
illegal (double const). You are confusing this with Foo * const foo; and const
Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system
------------------------------
From: Joop Marijne <[EMAIL PROTECTED]>
Subject: Re: reboot problem with adaptec 2940uw (aic7881rev1)
Date: Thu, 07 Jan 1999 10:01:38 +0100
Had same problem here to, with one of my newer servers the problem
disappeared. I think that was a newer card doesn't have this problem
anymore.
The older server was a P166 from 1995. My newer PII from 1998 was fine.
kind regards,
Joop Marijne
Johan Kullstam wrote:
> i've got a problem with rebooting a computer with adaptec 2940uw
> (aic7881rev1).
>
> the first time i boot up, everything goes well. the scsi card finds
> my harddrive at id 0 lun 0. the kernel boots. happy happy joy joy.
>
> the fun ends when i go to reboot. i type shutdown -r now but now the
> adaptec card prints a line about being itself and hangs. it does not
> go on to print stuff about configuration by typing Cntl-A. it does
> not find any disks at id 0 and lun 0.
>
> hitting the reset button does not help. the machine hangs at the same
> place. i must power-down and then re-power-up. what is going on here?
>
> --
> Johan Kullstam [[EMAIL PROTECTED]] Don't Fear the Penguin!
------------------------------
From: Navindra Umanee <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 6 Jan 1999 19:52:00 GMT
jedi <[EMAIL PROTECTED]> wrote:
>>The runtime version of Qt (just the .so file) is not a development tool.
>
> Back to spreading old lies again I see...
>
> [deletia]
>
> You know very well that a 'runtime version' would
> not all be sufficient even for a user workstation.
Sometimes you have a way with words... Elaborate, why is it a lie?
-N.
--
"These download files are in Microsoft Word 6.0 format. After unzipping,
these files can be viewed in any text editor, including all versions of
Microsoft Word, WordPad, and Microsoft Word Viewer." [Microsoft quote]
< http://www.cs.mcgill.ca/~navindra/editors/ >
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: blocksize / file write speed anomaly
Date: 6 Jan 1999 17:15:30 GMT
In article <[EMAIL PROTECTED]>,
Jerry Dinardo <[EMAIL PROTECTED]> writes:
> After looking at the problem further , I found that the problem has nothing
> to do with blocksize. The problem occurs with random disk IO.
>
> 1. write 25000 2KB blocks sequentially.
> 2. fsync
> 3. close
> 4. open output
> 5. write block 0,2,4,6 ...24998
> 6. write block 0,2,4,6 ...24999
> 7. fsync
> 8. close
>
> the program takes 10 seconds to do the sequential writes.
> It then takes 259 seconds to do the random writes.
>
> the same program takes 10 seconds and 16 (vs 259) seconds to run on an AIX
> system with slower disks than the linux system.
I have tried to replicate your results, but I don't get the same
results (on a PII 266):
$ ./testspeed
Wall time sequential write: 25000 2K byte blocks in 7 seconds (=7142.857 Kb/s)
Wall time random write: 25000 2K byte blocks in 10 seconds (=5000.000 Kb/s)
Could you post a copy of the test program?
Take care,
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: Bernd Strieder <[EMAIL PROTECTED]>
Subject: Re: blocksize / file write speed anomaly
Date: Thu, 07 Jan 1999 10:34:43 +0100
Hi all,
Jerry Dinardo wrote:
>
> My previous post should have said :
> 5. write block 0,2,4,6 ...24998
> 6. write block 1,3,5,7 ...24999
>
> however , even with just the even block writes my computer takes quite a long time.
>
> I have tested it on 4 ibm pc's (different speeds and linux versions).
> The only time , that I got results similar to yours was when I ran it on an AIX
> machine(model r30 - 4 pc 604 processors - 256 M memory).
>
> I also ran it on NT and I got some very interesting results. 5 second for the 1st
> loop and 6 seconds for the 2nd loop. The NT machine was the same model as the linux
> machine (although it had a lot of memory) so I am wondering if NT really fsynced
> ???
>
Running on my /tmp-partition, ext2fs, /dev/sda7
write_linux running ...
Duration 19 seconds
rwrite_linux running ...
12500 records written
12500 records written
Duration 358 seconds
:-o
During the run load peaked at 2.4 !! with nothing else running than just
xosview, I didn't touch mouse or keyboard. CPU usage was under 10%
nearly all of the time.
There was neither big memory footprint visible in xosview nor swapping.
Kernel 2.0.36, libc.so.5.4.44, AMD K6-2 300, Asus P5A 100MHz Mainboard
.....
Linux version 2.0.36 (root@forelle278) (gcc version 2.7.2.1) #1 Thu Nov
19 17:09
.....
ncr53c8xx: at PCI bus 0, device 10, function 0
ncr53c8xx: 53c810a detected
ncr53c810a-0: rev=0x11, base=0xdf000000, io_port=0xd800, irq=14
ncr53c810a-0: ID 7, Fast-10, Parity Checking
ncr53c810a-0: restart (scsi reset).
scsi0 : ncr53c8xx - revision 2.5f.1
scsi : 1 host.
ncr53c810a-0-<0,0>: using tagged command queueing, up to 4 cmds/lun
Vendor: QUANTUM Model: FIREBALL_TM2110S Rev: 300N
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
Vendor: MATSHITA Model: CD-ROM CR-504-J Rev: SS17
Type: CD-ROM ANSI SCSI revision: 02
ncr53c810a-0-<4,0>: FAST-5 SCSI 5.0 MB/s (200 ns, offset 8)
ncr53c810a-0-<4,0>: using tagged command queueing, up to 4 cmds/lun
Vendor: IBM Model: DCAS-32160 Rev: S65A
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sdb at scsi0, channel 0, id 4, lun 0
Vendor: IOMEGA Model: ZIP 100 PLUS Rev: J.66
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi removable disk sdc at scsi0, channel 0, id 5, lun 0
scsi : detected 3 SCSI disks total.
ncr53c810a-0-<0,0>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 8)
SCSI device sda: hdwr sector= 512 bytes. Sectors= 4124736 [2014 MB] [2.0
GB]
ncr53c810a-0-<4,0>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 8)
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 4226725 [2063 MB] [2.1
GB]
I must admit that the access pattern of this little program could be far
away from what fs routines might be optimized for. A short calculation
gives 358s / 25000 = 14ms average for every single access in the second
loop. This might be the time the harddisk needs to process a single
write. So it seems that Linux cannot merge those interleaved writes. To
do this, I think it would be necessary to read a large chunk of data
then change those interleaved blocks within the chunk and rewrite the
large chunk. Those additional reads would impact performance, if the
interleave becomes bigger, e.g. every 4th or 8th block is written. So
the optimal chunk size depends on what the actual software does.
Are there tunable parameters somewhere for something like this 'write
chunk size'.
Bye,
Bernd.
--
/|||\ Bernd Strieder
c+O-O+c
# | # HP: http://www.student.uni-kl.de/~strieder
##-##
###
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: silly question - Troll alert
Date: 1 Jan 1999 17:19:33 GMT
In article <[EMAIL PROTECTED]>,
ebatchelor <[EMAIL PROTECTED]> writes:
> I am a new user to Linux. I am an experienced MSDOS user, have written
> many batch files to accomplish what I want to do, and can recall the
> names of most DOS utilities I need to use. Of course, DOS sucks, but
> Windows cures many of the DOS shortcomings (long file names,
> multitasking (almost), etc.). Linux seems to incorporate the best of
> both worlds,
>
> but....
>
> Why the convoluted, hard to recall, someone thought it was funny in 1975
> utility names? It seems to me that BASH could be easily recoded to
> include easy to use and remember identifiers without giving up ANY
> functionality. I know it's part of the worship Unix thing, but it seems
> Linux could be more user friendly with little effort...
Use alias if you're pining for DOS. Don't forget, with Linux
(and UNIX), *you* are in charge. Why on earth recode bash
if you can say 'alias cp copy', until you're familiar with
your new environment?
Next you'll be asking why UNIX is case sensitive because
you keep hitting the Caps Lock key and would like cOPy
to be recognised.
> Just a question.
>
> Ed Batchelor
> innocent bystander
And not-so-innocent troll :-)
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Thu, 07 Jan 1999 10:42:57 GMT
Frank Sweetser wrote:
>
> [EMAIL PROTECTED] (Christopher Browne) writes:
>
> > On 05 Jan 1999 19:59:16 -0500, Frank Sweetser <[EMAIL PROTECTED]> wrote:
> > >Tristan Wibberley <[EMAIL PROTECTED]> writes:
> > >> 2) then a couple of libraries for parsing flat text will be most
> > >> appropriate no? Simplest to implement.
> > >
> > >agreed. this would be the first logical module to implement. i actually
> > >have two of them in front of me now (profile code from the kerberos package
> > >courtesy ted t'so, and libconfig from sunsite), one of which will probably
> > >end up getting stuffed into the flat text module.
> >
> > Indeed.
> >
> > Note that there will likely be two pieces:
> > a) Read the config, and
> > b) Write the config.
> >
> > The UNIX "approach" has been for these to be distinctly separated.
> > Which is, for things that are commonly referenced, but seldom changed, a
> > Good Thing.
> >
> > The "Windows Registry" approach is to have a unified database that puts
> > a common "API" onto both aspects. This is nice for those things that
> > get fiddled with all the time, but definitely makes *everything* in the
> > registry as vulnerable as the weakest link in/to the Registry.
>
> the best way to keep this seperation (which is a good thing) IMHO is by
> keeping the config in core. any updates should just be made to the in core
> copy. a seperate call can then be made to flush the config out (the entire
> config for files, only diffs for DB, etc).
>
The apps really don't need to know where the data is, only how to call
an interface function to get/set values. Ensuring completion of the
transaction could be a seperate "commit" call, or controled by
external configuration. Non commited changes could be handled by
creating a change delta file, that is then applied/merged the next time the
app runs. There are some interesting ways to do this, that can handle
multiple concurrent updates from several processes. File locking also
works but can cause config updates to block, then the calling code
has to deal with that possibility.
> > >> The talk of complex network databases is far too premature at the moment
> > >> - everyones always in such a rush to "innovate".
> > >
> > >you certainly have a point - there always seems to be a few people looking
> > >to implement the latest, sexiest theoretical paradigms, the type who want
> > >change for change's sake. however, sometimes change can be a good thing.
> > >i think that the opStore project has the potential to definatelly be a good
> > >thing.
> >
> > Everyone seems to want to come up with a "sexy" system that will
> > represent the "be-all and end-all."
> >
> > "I'll come up with the perfect configuration system, and it will make
> > me famous!"
> >
> > Unfortunately, actually implementing such a universal thing requires
> > that a *lot* of programs be modified. Which requires more effort than
> > anyone is likely to be willing to employ. It's *not* as simple as
> > coming up with the "perfect config system."
>
> i really don't see this library at being aimed at any *existing* programs.
> what i do see it being used by is new programs, and possible signifigantly
> new versions of existing programs.
>
> > If, in contrast, a scheme is set up that is *useful enough* and
> > *convenient enough* that it convinces *SOME* developers to adopt it,
> > thereby reducing the number of completely independent configuration
> > systems, that's GOOD ENOUGH.
> >
> > We don't need a "Unified Field Theory" of configuration systems; we need
> > something that's Good Enough, and perhaps that's somewhat better than we
> > have now.
>
> exact;u/
E=mc2 Hint solve for T.
>
> > >> I have to admit that the overriding values for local machines will be
> > >> awkward to implement using the network fs scheme, but I hope to figure
> > >> out a way of doing it that's quite easy to configure on the backend, and
> > >> transparent on the client. Maybe write some scripts to help.
> > >
> > >simply check the values in /etc/foo.defs, ~/.foocfg, then in /etc/foo.cfg,
> > >and have the last assigned value take precedence.
> >
> > Make sure it is documented clearly how this is to work, so that it is
> > *CLEAR* which files will be evaluated in what order. The problem with
> > (in contrast) X resource information is that the order of evaluation is
> > *not* clear.
>
> agreed. it's going to be rather interesting to declare a definitave order
> or precedence when the information can come from multiple sources, but i
> suspect any developers would drop it like a hot potatoe otherwise. there's
> already going to be a certain amount of metadata for each configuration
> object, so perhaps the precedence could be specified therein.
>
More stuff for /etc/app.conf ?
Note we could later do a sys.conf or daemons.conf,
Maybe it should be store.conf or opStore.conf, hmm
Thoughts?
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED] (Mike McDonald)
Subject: Re: GUI, The Next Generation
Date: 6 Jan 1999 20:50:33 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Derek B. Noonburg) writes:
> [EMAIL PROTECTED] (Peter Samuelson) writes:
> How about just drawing window title bars and borders? When you press
> the magic key, all of the window contents vanish, leaving you with
> just title bars and borders. You pick the window you want, it gets
> moved to the front, and then everything redraws. This wouldn't look
> as cool as translucency, but it would do pretty much what I wanted.
>
> - Derek
Just the title bar and the border probably aren't enough to choose the
correct window most of the time. An example would be having two xterms up, one
in the directory you want and the other off rlogged into some other host. It's
the contents of the window that allows you to pick.
Another problem to overcome would be determining which pixels become
transparent. Just using the background pixel of each window would probably
work most of the time for text windows, but for graphics windows, I'm not so
sure.
Mike McDonald
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: blocksize / file write speed anomaly
Date: 7 Jan 1999 10:03:49 GMT
[Posted and mailed]
In article <[EMAIL PROTECTED]>,
Jerry Dinardo <[EMAIL PROTECTED]> writes:
> My previous post should have said :
> 5. write block 0,2,4,6 ...24998
> 6. write block 1,3,5,7 ...24999
>
> however , even with just the even block writes my computer takes quite a long time.
>
> I have tested it on 4 ibm pc's (different speeds and linux versions).
> The only time , that I got results similar to yours was when I ran it on an AIX
> machine(model r30 - 4 pc 604 processors - 256 M memory).
>
> I also ran it on NT and I got some very interesting results. 5 second for the 1st
> loop and 6 seconds for the 2nd loop. The NT machine was the same model as the linux
> machine (although it had a lot of memory) so I am wondering if NT really fsynced
> ???
>
> I have included the program so you can see exactly what I did. (although netscape
> reformatted it)
Thanks. I've run it on my machine, and I'm getting results that
confirm my previous figures:
write_linux running ...
Duration 8 seconds
rwrite_linux running ...
12500 records written
12500 records written
Duration 18 seconds
I notice that you don't remove the file before running the
random write test. When removing the file and recreating it,
I get the following results:
write_linux running ...
Duration 8 seconds
rwrite_linux running ...
12500 records written
12500 records written
Duration 10 seconds
It's odd that writing to an existing file would take longer
than to a new file, so I tried it with an existing 51.2Mb
file in both circumstances (ie a simple open(..., O_WRONLY)):
write_linux running ...
Duration 10 seconds
rwrite_linux running ...
12500 records written
12500 records written
Duration 8 seconds
I reverted to your original program, and to get a better
view on the slow random write performance, I put calls to
pdur after the writing of the even and odd records, and
increased the number of records to 50000 (to make sure
that my 128Mb of memory has no influence on the results):
write_linux running ...
Duration 17 seconds
rwrite_linux running ...
25000 records written
Duration 14 seconds
25000 records written
Duration 35 seconds
Duration 41 seconds
The uneven writes are slower, but that's probably an
effect of the kernel caching the file. Without removing
and creating the files, I get the following results:
write_linux running ...
Duration 21 seconds
rwrite_linux running ...
25000 records written
Duration 13 seconds
25000 records written
Duration 34 seconds
Duration 41 seconds
And when the files are recreated before each test, I
get:
write_linux running ...
Duration 20 seconds
rwrite_linux running ...
25000 records written
Duration 7 seconds
25000 records written
Duration 21 seconds
Duration 27 seconds
which shows clearly the effect of the write caching on the
25000 even records.
Summary:
I can't get the results you're obtaining - maybe it's
related to the fact that I've got SCSI drives?
Take care,
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: [EMAIL PROTECTED] (Piniek (aka Piotr Ingling))
Subject: Re: Kernel v2.2
Date: Wed, 06 Jan 1999 20:58:00 GMT
Reply-To: [EMAIL PROTECTED]
Dnia Wed, 06 Jan 1999 08:37:32 -0800, Edward Lee <[EMAIL PROTECTED]>
napisa�(a):
>Thank you, i did not know about the name change and i did not look hard
>enough.
>I found it at
>ftp:ftp.cdrom.com/pub/linux/tsx-11/kernels/v2.1/modutils-2.1.13.src.tar.gz
>
>I hope this will help several other people having the same problem.
>
Hmm... The latest one is 2.1.121 - it's in the v2.1 dir of the kernel site.
Look at www.kernel.org for your local mirror.
Piotr Ingling
e-mail: [EMAIL PROTECTED]
------------------------------
From: SONE Takeshi <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Thu, 07 Jan 1999 18:06:58 +0900
Andy Lutomirski wrote:
> You do NOT need the NT system call interface. At all. This is
> undocumented, and Mark Russinovich is the only person who uses it.
I know...
I just thought that if you develop NT driver interface, you can share
the effort for developing syscall interface for applications to run.
Kernel mode NT emulator should be more compatible than user mode one
(Wine), because it can run all *real* (M$) DLLs.
I suppose even real WIN32K.SYS can run in kernel mode, it is much like
drivers.
>
> You will want a bogus service table so drivers can think they are modifying
> it.
>
> Andy
>
> SONE Takeshi <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >I used to think of kernel-level NT emulator for linux.
> >One part of it is PE EXE/DLL loader, which is rather trivial.
> >The other part is NT system call handler.
> >AFAIK, all NT API call become INT XXh kernel call (through NTDLL.DLL
> >etc).
> >They can be handled by a kernel module.
> >This part, NT kernel emulator, naturally becomes the layer to help NT
> >drivers to run.
> >
> >Inaki Castillo wrote:
> >>
> >> > Actually, WDM starts with the NT Driver model. We would probably start
> >> > with the NT DKK.
> >> >
> >>
> >> Have you any idea of what are you saying ?
> >>
> >> NT DDK is nothing by itself, you should reproduce all NT Kernel
> >> components to do any simple piece of driver to work. That is all the
> >> operating system. Win32 is in fact a layer above that.
> >>
> >> Maybe is better to move to NT.
> >
> >--
> >SONE Takeshi ����
> ������
> >mailto:[EMAIL PROTECTED] Office Craftsman Arts
> >http://www.cma.co.jp/~ts1/
--
SONE Takeshi ���� ������
mailto:[EMAIL PROTECTED] Office Craftsman Arts
http://www.cma.co.jp/~ts1/
------------------------------
** 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
******************************
