Linux-Development-Sys Digest #710, Volume #7 Mon, 27 Mar 00 17:13:25 EST
Contents:
SCSI-3 DST cmd ("mike landrus")
Re: POSIX timer implementation available. ("Robert H. de Vries")
Hard disk DMA access, SMP bug? (The Hedge Fox)
Re: Linux Serial Port Interrupt Problem (Josh Rovero)
Re: SHM and kernel 2.3.5x (Martin Boening)
Re: POSIX timer implementation available. (Kaz Kylheku)
wine new version (Jan J. Esser)
wine (Jan J. Esser)
Re: wine new version (Kaz Kylheku)
Re: SHM and kernel 2.3.5x (Martin Boening)
ndbm.h (Corel Linux) ("NJB")
Re: need fsck source code (Allin Cottrell)
----------------------------------------------------------------------------
From: "mike landrus" <[EMAIL PROTECTED]>
Subject: SCSI-3 DST cmd
Date: Mon, 27 Mar 2000 14:25:39 -0600
I was testing the DST command (1Dh) under RedHat 6.1, and found that Linux
is forcing the "self-test code" to the LUN. These bits were reserved under
SCSI-2, but are used in SCSI-3 to set the self test code.
I'm using the ioctl command (SCSI_IOCTL_SEND_COMMAND):
unsigned char *cmd;
memset(_buffer, 0, sizeof(_buffer));
*((int *) _buffer) = 0; // length of input data
*(((int *) _buffer) + 1) = 0xff; // length of output _buffer
cmd = (unsigned char *) (((int *) _buffer) + 2);
cmd[0] = 0x1D; // SEND DIAGNOSTIC
cmd[1] = 0x30; // short test
cmd[2] = 0x00; // (reserved)
cmd[3] = 0x00; // parameter list len (MSB)
cmd[4] = 0x00; // parameter list len (LSB)
cmd[5] = 0x00; // control
status = ioctl(fileno(_infile), 1 /*SCSI_IOCTL_SEND_COMMAND*/ , _buffer);
if (status) {
printf("Unable to send DST cmd %02xh : %s\n"
, STcode, fDisplayTargetErr(status));
}
Does anyone know of a way to fix this?
I was told by redhat to use the generic driver sg?, but this is doing the
same as sd?.
I tried modifying the sg.c file (linne 437, ver 2.2.14), but have yet to
make it work.
thanks,
mike
------------------------------
From: "Robert H. de Vries" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: POSIX timer implementation available.
Date: Mon, 27 Mar 2000 22:31:13 +0200
Kaz Kylheku wrote:
> On Mon, 27 Mar 2000 21:24:41 +0200, Robert H. de Vries <[EMAIL PROTECTED]> wrote:
> >At http://www.rhdv.cistron.nl/posix.html you can find a complete kernel based
> >implementation of the complete set of POSIX timer functions. This
> >implementation is 100% compliant.
>
> This implementation is far from complete. Completely absent is the support
> for SIGEV_THREAD, which I view as a notification mechanism which eclipses
> SIGEV_SIGNAL in usefulness and importance.
Complete in the sense of the RT-POSIX specification. AFAIK that specification does
not mention SIGEV_THREAD. However you are right, that in the context of the
POSIX thread specification, such
a mechanism has been foreseen.
> My user-space implementation provides the SIGEV_THREAD support described in the
> Single UNIX Specification. This support allows the user to specify that
> a timer notifiation be executed in the context of a thread which calls a
> specified function. What is more, the user can choose the attributes of
> the thread (other than making the thread joinable, which is explicitly
> forbidden.)
If I am not mistaken SIGEV_THREAD is implemented by a signal handler
under IRIX 6.5. A special signal is sent to the thread, which invokes a special
signal handler which in turn creates a new thread.
> Having a notification function invoked in a thread is far more useful than the
> delivery of a signal, because you can do more in the context of a thread than
> in the context of a signal: you have full use of the library functions,
> including the POSIX threading functions themselves. Such a notification
> call can acquire and release mutex locks, perform I/O, allocate memory, etc.
But you do not *have* to handle a signal inside a signal handler. You can also
wait synchronously on the arrival of one.
> Signal notification makes the most sense in single threaded applications.
> Signals and multi-threaded programming usually make a poor mixture.
I do not agree, please explain.
> I'm not saying any of this to criticize your work; but I think that as long as
> the threading implementation (LinuxThreads) is based heavily in user space,
> than at least the SIGEV_THREAD feature of the POSIX timers also must be in user
> space, because it requires the services of the LinuxThreads library in order to
> create a proper LinuxThreads thread.
I agree completely.
> What we do need from the kernel to make the timers more fully compliant is
> support for the new style signals. User space can use a dedicated thread to
> deliver the signals, but without the advanced support, I can only use
> pthread_kill() to give an ``old-fashioned'' signal to a particular thread. The
> timer spec allows the user to use new features of sigaction to register a new
> kind of signal function which receives all kinds of new context info (which,
> among other things, can distinguish whether the signal was caused by an
> old-style kill or the new function sigqueue.). An of course, the shared signal
> queue is needed so that the kill goes to any thread within the ``process''
> which has the signal unblocked, rather than to a particular thread.
> If all this was in place, then the dedicated ``signal thread'' I hacked
> up would simply call sigqueue() instead of pthread_kill() and the kernel
> would take care of the rest.
I guess you have also looked at the other patch available from the same site? It
is a first stab at the implementation of shared signal queues to make it possible
to be compliant with the POSIX thread signal queuing spec.
> I don't see a big need for the kernel to actually manage these timer objects
> and handle the expiry. Though a mixed approach could work; the kernel could
> perform the SIGEV_SIGNAL events itself, and handle the timing of SIGEV_THREAD
> ones but defer their processing to user space: this is analogous to using
> a kernel web server to handle static page requests, and passing the clumsy
> dynamic stuff to a user space server. It would avoid having to context
> switch a a user space thread to deliver a signal, which is a big win.
There are two big problems with user space timers based on the set/getimer combo:
You cannot properly implement timer overruns
You cannot have two independent timers in one process.
My patch addresses both problems.
> Another issue is that struct sigevent is used in interfaces other than the
> timer. What about providing the notice of asynchronous I/O completion as
> a SIGEV_THREAD? It might be useful for the library to have a common module
> for managing and dispatching these threads. (I haven't addresses this in
> my timer module, which maintains a internal threads that are dedicated for
> waiting on their timer queues and doing the callouts.)
I guess that the implementation method taken by IRIX 6.5 could also work in Linux.
The pthread library reserves one special signal for thread creation, combined with
a special signal handler which actually creates the thread. I think this could
work.
Robert
--
Robert de Vries
[EMAIL PROTECTED]
------------------------------
Subject: Hard disk DMA access, SMP bug?
From: [EMAIL PROTECTED] (The Hedge Fox)
Date: Mon, 27 Mar 2000 20:34:37 GMT
We tried some Maxtor 40GB UDMA66 5400rpm and IBM 34GB UDMA66 7200rpm
drives on some Dell 410, 420's with dual P-II and P-III CPUs using
the 2.2.14 kernel compiled for SMP. The distribution was Mandrake 7.0.
Using hdparm to set DMA access resulted in occasional corruption
of data on the disk - bad enough to require a mkfs. Switching to
PIO access fixed the problem. Setting unmask_irq didn't seem to
hurt at all. The corruption occurred with ext2, ext3 and reiserfs.
Running the same hard disks with UDMA on a uniprocressor machine w/o SMP
but the same kernel and distribution was OK, none of the problems
on the dual CPU machines.
Has anyone else encountered this problem? Why would DMA access be
a problem with an SMP kernel?
--
C. Chan < [EMAIL PROTECTED] >
PGP Public Key: finger [EMAIL PROTECTED]
------------------------------
From: Josh Rovero <[EMAIL PROTECTED]>
Subject: Re: Linux Serial Port Interrupt Problem
Date: Sun, 26 Mar 2000 08:55:55 -0500
[EMAIL PROTECTED] wrote:
>
> I have been working on writing a device driver for
> linux that operates as an ethernet device but uses
> the serial port (COM1).
Take a look at termnetd, which is a serial proxy
(to tcp/ip).
--
P. Josh Rovero email: [EMAIL PROTECTED]
web: http://www.connix.com/~provero
------------------------------
From: [EMAIL PROTECTED] (Martin Boening)
Subject: Re: SHM and kernel 2.3.5x
Date: 27 Mar 2000 21:01:47 GMT
Hi there,
[EMAIL PROTECTED] (Aric Cyr) writes:
>It's really quite easy, after a little trial and error and code reading you
>can figure it out. What you want to do is "mount none /var/shm -t shm" and
>make sure that the directory "/var/shm" exists. This is similar to mounting
Yep, it sounds real easy. However, when I do try that (and the fstab entry in
Changes:
none /var/shm shm defaults 0 0
)
my mount barfs:
mount: wrong fs type, bad option, bad superblock on none,
or too many mounted file systems
I should mention that I am running Slackware 7.0.0. And I have updated the
few packages (modutils, pppd) The rest meet the requirements, unless I'm
mistaken.
That's because my mount (2) returns EINVAL (a little strace output):
readlink("/var", 0xbfffd9a0, 4094) = -1 EINVAL (Invalid argument)
readlink("/var/shm", 0xbfffd9a0, 4094) = -1 EINVAL (Invalid argument)
open("/etc/mtab", O_RDONLY) = 3
fstat(3, {...}) = 0
mmap() = 0x40014000
read(3, "/dev/sda2 / ext2 rw 0 0\n/dev/sd"..., 4096) = 118
read(3, "", 4096) = 0
close(3) = 0
munmap(0x40014000, 4096) = 0
rt_sigprocmask(0, 0xbffff798, 0, 0x8, 0) = 0
mount("none", "/var/shm", "shm", 0xc0ed0000, 0x8057f00) = -1 EINVAL (Invalid argument)
rt_sigprocmask(0x1, 0xbffff798, 0, 0x8, 0x1) = 0
write(2, 0xbfffd11c, 98mount: wrong fs type, bad option, bad superblock on none,
or too many mounted file systems
) = 98
stat("none", 0xbffff7cc) = -1 ENOENT (No such file or directory)
_exit(32) = ?
/var/shm exists as a normal directory, BTW (and my clock was way off, when I
created it :-)):
# ls -ld /var/shm
drwxr-xr-x 2 root root 4096 Jan 1 1997 /var/shm/
According to ldd, mount only needs libc.so.6, so I guess mount(2) is in libc.
Now I checked the requirements in Changes again!
It says there I need at *least* "Linux libc6 C Library 2.0.7pre6"
If I read the slackware 7.0.0 docs right, what I have is the version 2.1.2,
which meets that criterium (1 >= 0 :-)).
And the kernel config file contains CONFIG_SYSVIPC=y, so I suppose I have
SHM in there.
Any hints? Anybody?
BTW, just for kicks I umounted everything except '/', so the 'too many mounted
file systems' is not the anser I'm looking for.
TIA
Be seeing you
Martin
--
Martin Boening, MB3792 | EMail: [EMAIL PROTECTED]
A black cat crossing your path signifies that the animal is going somewhere.
-- Groucho Marx
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: POSIX timer implementation available.
Reply-To: [EMAIL PROTECTED]
Date: Mon, 27 Mar 2000 21:07:57 GMT
On Mon, 27 Mar 2000 22:31:13 +0200, Robert H. de Vries <[EMAIL PROTECTED]> wrote:
>Kaz Kylheku wrote:
>
>> On Mon, 27 Mar 2000 21:24:41 +0200, Robert H. de Vries <[EMAIL PROTECTED]> wrote:
>> >At http://www.rhdv.cistron.nl/posix.html you can find a complete kernel based
>> >implementation of the complete set of POSIX timer functions. This
>> >implementation is 100% compliant.
>>
>> This implementation is far from complete. Completely absent is the support
>> for SIGEV_THREAD, which I view as a notification mechanism which eclipses
>> SIGEV_SIGNAL in usefulness and importance.
>
>Complete in the sense of the RT-POSIX specification. AFAIK that specification does
>not mention SIGEV_THREAD. However you are right, that in the context of the
>POSIX thread specification, such
>a mechanism has been foreseen.
>
>> My user-space implementation provides the SIGEV_THREAD support described in the
>> Single UNIX Specification. This support allows the user to specify that
>> a timer notifiation be executed in the context of a thread which calls a
>> specified function. What is more, the user can choose the attributes of
>> the thread (other than making the thread joinable, which is explicitly
>> forbidden.)
>
>If I am not mistaken SIGEV_THREAD is implemented by a signal handler
>under IRIX 6.5. A special signal is sent to the thread, which invokes a special
>signal handler which in turn creates a new thread.
I was thinking of that possibility as well. A special signal which bypasses
the shared queue and goes directly to a dedicated handler.
>> Having a notification function invoked in a thread is far more useful than the
>> delivery of a signal, because you can do more in the context of a thread than
>> in the context of a signal: you have full use of the library functions,
>> including the POSIX threading functions themselves. Such a notification
>> call can acquire and release mutex locks, perform I/O, allocate memory, etc.
>
>But you do not *have* to handle a signal inside a signal handler. You can also
>wait synchronously on the arrival of one.
>
>> Signal notification makes the most sense in single threaded applications.
>> Signals and multi-threaded programming usually make a poor mixture.
>
>I do not agree, please explain.
You can't make logical assertion like ``mixing signals and threads is wrong''.
It's just that it's one of these things that is difficult and error prone.
Usually, signals are used for asynchronous things that can be better handled by
having an additional thread.
Signal handlers cannot do certain useful things, like call pthread_* functions,
or any other functions that are not async safe.
>
>There are two big problems with user space timers based on the set/getimer combo:
>You cannot properly implement timer overruns
>You cannot have two independent timers in one process.
>My patch addresses both problems.
I addressed the second problem by not using setitimer and getitimer but rather
a collective of threads.
All timers that deliver signals are assigned to a special ``signal thread''
which kills on contract, so to speak. ;)
Overruns are a problem, however. Kernel help there is definitely essential.
It's not clear to me what utility the overrun counting has (other than
diagnostic value), but it must be useful to someone somewhere.
More details: the timer expiry is performed by simple queues. A thread executes
pthread_cond_timedwait() until the absolute wakeup time implied by the first
timer in the chronological queue. It then removes the timer from the queue and
performs the appropriate action: requeueing the timer if it is periodic,
calling the callout or delivering the signal.
Thus we leverage the kernel by way of pthread_cond_timedwait which (in Linux)
relies on nanosleep().
>I guess that the implementation method taken by IRIX 6.5 could also work in Linux.
>The pthread library reserves one special signal for thread creation, combined with
>a special signal handler which actually creates the thread. I think this could
>work.
Also, a thread having the required attributes could simply be pulled out of an
existing pool. I like that.
I have a problem with threads being created within signal handlers. ;)
But that is an implementation detail that can be overcome; at worst by
getting the signal synchronously with sigwait().
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Jan J. Esser)
Subject: wine new version
Date: Mon, 27 Mar 2000 21:25:44 GMT
Reply-To: [EMAIL PROTECTED]
I just installed Linux Suse 5.2 and discovered wine an
Windowssimulator, i tried to use winamp, but it doesn't work because
of missing directsound, itried some other programs, but no one worked
because of any not working microsoft tool, perhaps there is new
version, but i don't know where. Please Help!
------------------------------
From: [EMAIL PROTECTED] (Jan J. Esser)
Subject: wine
Date: Mon, 27 Mar 2000 21:25:44 GMT
Reply-To: [EMAIL PROTECTED]
Needing an program simulating Windows under x-window system (Direct
Sound, DirectX?)
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: wine new version
Reply-To: [EMAIL PROTECTED]
Date: Mon, 27 Mar 2000 21:27:46 GMT
On Mon, 27 Mar 2000 21:25:44 GMT, Jan J. Esser <[EMAIL PROTECTED]> wrote:
>I just installed Linux Suse 5.2 and discovered wine an
>Windowssimulator, i tried to use winamp, but it doesn't work because
Winamp is one of those programs that you don't need to run under Wine
because there are ``native'' equivalents for Linux.
Go to www.freshmeat.net and search for xmms.
The WINE page is at www.winehq.com. WINE also has its own newsgroup and mailing
lists so you should ask your questions there.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Martin Boening)
Subject: Re: SHM and kernel 2.3.5x
Date: 27 Mar 2000 21:30:43 GMT
Hi there,
forget my latest scribblings please. Sometimes the simplest solution is the
last one I find (see below).
[EMAIL PROTECTED] (Martin Boening) writes:
>Hi there,
>[EMAIL PROTECTED] (Aric Cyr) writes:
[I quoted it once - that's enough ]
>Yep, it sounds real easy. However, when I do try that (and the fstab entry in
>Changes:
>none /var/shm shm defaults 0 0
>)
[ stuff deleted ]
My internal spelling checker switched on when I noted an "invalid option" in
the dmesg output: in my actual fstab entry defaults was missing its trailing
's'. That explained everything, of course.
Now the shm seems to be working as documented.
Thanks for listening,
Martin
--
Martin Boening, MB3792 | EMail: [EMAIL PROTECTED]
A black cat crossing your path signifies that the animal is going somewhere.
-- Groucho Marx
------------------------------
From: "NJB" <[EMAIL PROTECTED]>
Subject: ndbm.h (Corel Linux)
Date: Mon, 27 Mar 2000 22:50:46 +0100
Hi - I've been trying to use ndbm in corel linux, in other systems I've also
had to include /system/mode.h (for O_RDRW etc.) but this doesn't seem to
exist and I keep getting compile errors in the vain of 'dbm_open not
defined' - there also does not appear to be any man pages for this, & I'm
presuming other areas also.
Any help would be gratefully received, thanks - Nigel
------------------------------
From: Allin Cottrell <[EMAIL PROTECTED]>
Subject: Re: need fsck source code
Date: Mon, 27 Mar 2000 16:48:35 -0500
Hasan Jamal wrote:
>
> I need the source code of "fsck", the file system checker under the
> /sbin
> directory.
> I have searched most of the ftp archives related to linux and did not
> find anywhere.
> I got RedHat & SuSe distribution, in none of them I found.
> I would be grateful if anybody can give me the source code or the ftp
> site.
http://web.mit.edu/tytso/www/linux/e2fsprogs.html
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
------------------------------
** 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
******************************
