Linux-Development-Sys Digest #806, Volume #7 Thu, 27 Apr 00 03:13:14 EDT
Contents:
sleep_on() and wake_up() (Badrinath Venkatachari)
Re: cli() & sti()... (Kaz Kylheku)
Re: sleep_on() and wake_up() (Kaz Kylheku)
How many pty's ("Dave")
Re: Can I install a new video driver in Corel Linux? (Tim Roberts)
Re: How legal is it??? (Joe Bowser)
Re: Time for the MS-rats to desert (@ .)
Re: sleep_on() and wake_up() (Badrinath Venkatachari)
Help:"Out of memory" after first compile kernel. (Pichet Ratanayant)
bz2 file (kartika garg)
Re: sleep_on() and wake_up() (Kaz Kylheku)
Re: bz2 file (Robert Schiele)
help: timer freezes after write in driver (Jan-Willem Stroeken)
----------------------------------------------------------------------------
From: Badrinath Venkatachari <[EMAIL PROTECTED]>
Subject: sleep_on() and wake_up()
Date: Wed, 26 Apr 2000 21:02:21 -0700
Hi,
Suppose there are multiple processes sleeping on the same wait_queue
using the sleep_on() function. When a wake_up() on that wait_queue is
issued (on an event), does it result in waking up all the processes
sleeping on the wait_queue or any one of them ???
I would like to be able to wake_up all the processes. In the event, the
above mentioned algorithm does not work for that, can any one please
tell me how I can accomplish it ??
TIA
badri
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: cli() & sti()...
Reply-To: [EMAIL PROTECTED]
Date: Thu, 27 Apr 2000 03:28:59 GMT
On Thu, 27 Apr 2000 00:44:07 GMT, Bill Waddington
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> On Wed, 26 Apr 2000 16:50:21 GMT, Bill Waddington
>> <[EMAIL PROTECTED]> wrote:
>> >In article <[EMAIL PROTECTED]>,
>> > [EMAIL PROTECTED] wrote:
>> >> On Wed, 26 Apr 2000 14:15:34 GMT, Bill Waddington
>> >> <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> >
>> >> >> The point I'm trying to get to is that cli() and sti() are
>> >obsolete,
>> >> >legacy
>> >> >> operations---do not use them! Use spinlocks. The operations
>> >> >spin_lock_irqsave()
>> >> >> and spin_unlock_irqrestore() work correclty under SMP and on a
>uP
>> >> >kernel they
>> >> >> collapse into save_flags(); cli() and restore_flags().
>> >> >
>> >> >Hello,
>> >> >
>> >> >When using the above, does one place similar spinlocks in the
>> >interrupt
>> >> >code?
>> >>
>> >> Yes.
>> >>
>> >> --
>> >> #exclude <windows.h>
>> >>
>> >
>> >Thanks,
>> >
>> >Sorry to be such a blockhead ... are the lock and unlock ops used in
>the
>> >interrupt code spin_lock_irqsave()and spin_unlock_irqrestore() or
>> >some related lock and unlock ops? (& if so, what are they, please)
>>
>> No, you spin_lock_irqsave() in interrupt code as well. Here
>> are some rules of thumb: if you know that you are running in a context
>> that has interrupts enabled you can use spin_lock_irq() and
>> spin_unlock_irq(). These functions don't bother saving and restoring
>> flags. If you don't know whether interrupts are masked or unmasked
>> on the local processor, then use spin_lock_irqsave() and
>> spin_unlock_irqrestore().
>>
>> In other words, in places where you would use cli() and sti() on 2.0
>or older
>> kernels, you can use spin_lock_irq() and spin_unlock_irq(). In places
>where
>> you would have used save_flags(flags); cli(); and restore_flags(), you
>now use
>> spin_lock_irqsave() and spin_unlock_irqrestore().
>>
>> Avoid using spin_lock and spin_unlock since they don't do anything
>with
>> interrupts. They can't protect processes from ISR's. What they can
>> do is protect critical regions against concurrent access by processes,
>> as long as those region is not executed by interrupt code.
>>
>> You must not reschedule while holding a spin lock, otherwise some
>process will
>> come along and try to acquire the lock which is held by the suspended
>process.
>> By doing so, it hog the CPU and prevent the suspended process from
>releasing
>> the lock. If you need long locks among processes, use semaphores.
>>
>> >Do I understand correctly from the previous discussion that
>cli()/sti()
>> >still function on SMP hardware, but at the expense of locking out
>> >interrupts across all processors?
>>
>> Sort of. It's pretty bletcherous; to understand it fully, you have to
>> follow the source code, of course. There are some concessions made;
>> it's not a full lockout just a reasonable lockout.
>>
>> --
>> #exclude <windows.h>
>>
>
>Hello again,
>
>May we chase this a bit farther? I replaced my save flags/cli/restore
>flags code with spin_lock_irqsave and spin_unlock_irqrestore. Things
>seem to work just fine (on a uniprocessor PC).
>
>Now I wonder if it should be working at all.
>
>What is going on in the strategy routine is:
>
>spin_lock_irqsave()
>launch a DMA xfer
>interruptible_sleep_on_timeout()
>spin_unlock_irqrestore()
That is very bad. You must not reschedule a process while its processor is
holding a spinlock. You must release the spinlock before sleeping.
This is neatly analogous to releasing a mutex when waiting on a condition
variable. (In fact I managed to wrap spinlocks and wait queues behind
a mutex and condition variable programming interface: see
http://users.footprints.net/~kaz/lmc.html)
>the interrupt handler does:
>
>spin_lock_irqsave()
>if it is our int, set a flag
>spin_unlock_irqrestore()
>if(flag) wake_up_interruptible()
>
>What puzzles me is how am I getting through the interrupt code if I am
>still holding the spinlock?
Because you are on a uniprocessor, there is no lock to speak of. If you
look at the header file <asm/spinlock.h> everything should be clear.
If you compile without __SMP__, then the following equivalence is set
up:
#define spin_lock_irqsave(lock, flags) \
do { save_flags(flags); cli(); } while (0)
#define spin_unlock_irqrestore(lock, flags) \
restore_flags(flags)
>This must be a common problem in a device driver (I know that it is in
>mine). How is this handled by the big boys?
How it is handled is that you atomically give up the lock and wait, just like
the pthread_cond_wait() operation in threaded application programming.
Instead of calling interruptible_sleep_on() what you do is you explicitly
queue the task onto the wait queue, set its state to TASK_INTERRUPTIBLE
and call the scheduler.
*After* enqueuing the task, you check for the wakeup predicate and bypass
the call to the scheduler. Thus there is no opportunity for a lost wakeup.
If the wakeup is subsequently delivered after the predicate check
but before the reschedule, that is no problem! The task is already queued to
wait, and the waker will simply cause it to be removed from the wait queue and
made runnable. Thus the call to the scheduler will not cause a suspension but
most likely short circuit (or at worst, put the task into the back of the run
queue).
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: sleep_on() and wake_up()
Reply-To: [EMAIL PROTECTED]
Date: Thu, 27 Apr 2000 03:29:36 GMT
On Wed, 26 Apr 2000 21:02:21 -0700, Badrinath Venkatachari <[EMAIL PROTECTED]>
wrote:
>Hi,
> Suppose there are multiple processes sleeping on the same wait_queue
>using the sleep_on() function. When a wake_up() on that wait_queue is
>issued (on an event), does it result in waking up all the processes
>sleeping on the wait_queue or any one of them ???
All.
--
#exclude <windows.h>
------------------------------
From: "Dave" <[EMAIL PROTECTED]>
Subject: How many pty's
Date: Thu, 27 Apr 2000 03:47:16 GMT
can be configured on a 2.x.x kernal?
I really want 512 or 1024 if I can get that many. I examined tty.h
in the kernal source and found that NR_PTYS is defined to be 256
and a warning not to mess with it unless .....
Is it really necessary to hack the kernal to increase the count?
I considered just hacking /dev/MAKEDEV to increase the number,
but I think this may confuse the kernal if I also don't hack pty.[ch] :-(
What a mess.
Am I stuck with 256?
I hate to say this but solaris is so easy here, just edit /etc/system
to change cnt_pty to what ever number you need and reboot.
Oh well, maybe on a later kernal release this sort of thing will
be dealt with.
Dave
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: Can I install a new video driver in Corel Linux?
Date: Wed, 26 Apr 2000 21:03:26 -0700
[EMAIL PROTECTED] (Pipegeek) wrote:
>Corel Linux does not support my video card by default (Voodoo Banshee), but I
>have found a driver online for it. However, I have heard Corel Linux relies
>heavily on hardware autodetection. If the driver is not there during the
>install, can it be used afterwards (i e, can I add a device without
>autodetection)?
Sure. It's just Linux. You should just be able to overwrite
/usr/X11R6/bin/XF86_SVGA with your new version, and off you go.
There isn't all that much autodetection for X yet.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: Joe Bowser <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.asm.x86,comp.lang.c++,comp.os.linux.development.apps
Subject: Re: How legal is it???
Date: 27 Apr 2000 04:11:51 GMT
On 25 Apr 2000, _Steven Chang wrote:
> Hi there,
>
> I'm thinking of creating a stealth application that will automatically
> launch itself when the OS starts. I would like the application to
> record the keystrokes made by users, and possibly the mouse movements as
> well. Then, probably buffer these data and have them sent to a server
> over the internet periodically.
>
> Assuming that the user has provided consent for having this program
> installed on one's computer, how legal will it be for such program to be
> running under
>
> a) Linux?
> b) Windows 98/NT/2000?
>
This is not illegal at all if you have the person's consent, but I
wouldn't do something like this unless you were NEVER going to give out
the server, and you have to make sure that the client NEVER leaves the
development area (office, lab, house, what would the proper term be).
Does it really matter what OS it is, it doesn't change the legality one
bit.
Joe Bowser
------------------------------
Crossposted-To:
comp.os.linux.advocacy,comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy,comp.os.linux.networking,comp.os.linux.security,comp.os.ms-windows.networking.tcp-ip,alt.conspiracy.area51
From: @ .
Subject: Re: Time for the MS-rats to desert
Date: Thu, 27 Apr 2000 05:19:01 GMT
You are a moron
In article <[EMAIL PROTECTED]>, John Unekis <[EMAIL PROTECTED]> wrote:
>There is an old joke about a hooker who goes into a bar, orders a drink, and
> pays
>with a 20-dollar bill.
>The bartender holds the 20 up to the light and remarks - "Hey, you can't use
>this, this $20 is counterfeit!"
>To which the hooker exclaims - "Oh, no, I've been raped!"
>
>Now that Microsoft stock is in free-fall, quickly heading for under $50/share,
>there must be a lot
>of Code-Ho's up in Redmond who have sold their souls to Bill for stock options,
>dreaming of
>retiring young and rich, who are now realizing they've been raped.
>
>I noticed that Microsoft is reimbursing its senior managers for their stock
>losses with new stock options which
>are adjusted for the lower share price.
>
>For regular employees, MS is encouraging them to take a "long term view".
>
>The only thing long-term at Microsoft is the duration of the screwing that
>employees are getting.
>
>I imagine that it is going to become very difficult to find u-haul trailers in
>the Redmond area as more and more victims of the "Cult of Bill" awaken from
> their
>trances and decide to show Microsoft a long-term view of their ass.
>
>Remember all you Microserfs, the ones who bail first will get all the good jobs
>down in Silicon valley, the stragglers will end up fetching them coffee....
>
------------------------------
From: Badrinath Venkatachari <[EMAIL PROTECTED]>
Subject: Re: sleep_on() and wake_up()
Date: Thu, 27 Apr 2000 01:18:33 -0700
Hi,
Thanks a lot for the reply...Kaz. If I had processes put themselves to sleep
(based on some criterion), is it ok for me to wake them out of sync from an
interrupt handler ?? or do I need to do something like this (in the process's
context itself)..
some_function_in_normal_context()
{
if (some condition)
{
/* code */
sleep_on(&wait_q);
/*more code */
return;
}
/* code */
wake_up(&wait_q);
/*more code */
return;
}
If it is legal to wake_up processes at interrupt time...is there a chance that
schedule() can be called (since all the processes are runnable after the wake_up
call) before I exit the interrupt handler ?? What do I do to ensure that it does
not happen (in case there is a chance that schedule() can be called before I exit
the interrupt handler) ?
Also is it recommended that processes be woken_up in the bottom half than at
interrupt time...since the bottom_half is executed at a safer time..
sorry about the "many" questions.... :-)
TIA
badri
Kaz Kylheku wrote:
> On Wed, 26 Apr 2000 21:02:21 -0700, Badrinath Venkatachari <[EMAIL PROTECTED]>
> wrote:
> >Hi,
> > Suppose there are multiple processes sleeping on the same wait_queue
> >using the sleep_on() function. When a wake_up() on that wait_queue is
> >issued (on an event), does it result in waking up all the processes
> >sleeping on the wait_queue or any one of them ???
>
> All.
>
> --
> #exclude <windows.h>
------------------------------
From: Pichet Ratanayant <[EMAIL PROTECTED]>
Subject: Help:"Out of memory" after first compile kernel.
Date: Thu, 27 Apr 2000 11:51:44 +0700
Hi All,
I am compile kernel follow this step,
make dep
make clean
make bzImage
After that, I am use "linuxconf" to install kernel, reboot system and
see following message,
Out of memory
-- System halted
My environment are
Red Hat Linux 6.0, Pentium II 450, 128M byte of RAM.
Please help me to fix this problem.
Thank in advance.
Pichet R.
------------------------------
From: kartika garg <[EMAIL PROTECTED]>
Subject: bz2 file
Date: Thu, 27 Apr 2000 11:37:18 +0530
Can you not download .bz2 files to windows.I have noticed that when I
download .bz2 files to windows and than ftp it to linux it gives an
error--"files are probably corrupt" but if I download them on linux then
there is no problem. Can somebody tell me the reason???
Thanx in advance
Kartika
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: sleep_on() and wake_up()
Reply-To: [EMAIL PROTECTED]
Date: Thu, 27 Apr 2000 06:15:07 GMT
On Thu, 27 Apr 2000 01:18:33 -0700, Badrinath Venkatachari <[EMAIL PROTECTED]>
wrote:
>Hi,
> Thanks a lot for the reply...Kaz. If I had processes put themselves to sleep
>(based on some criterion), is it ok for me to wake them out of sync from an
>interrupt handler ?? or do I need to do something like this (in the process's
>context itself)..
>
>some_function_in_normal_context()
>{
> if (some condition)
> {
> /* code */
> sleep_on(&wait_q);
> /*more code */
> return;
> }
>
> /* code */
> wake_up(&wait_q);
> /*more code */
> return;
>}
This won't work. If ``some condition'' is true, the process will sleep.
Interrupt doesn't wake it up, it will continue sleeping indefinitely.
A process cannot possibly execute its own wake_up(), because by definition it
is then not sleeping, so what is the point?
Also, on another note, there is a potential race condition with code like:
if (!event_ready)
sleep_on(&event_queue);
What if the interrupt makes event_ready true, and wakes up the queue *before*
the process executes sleep_on? This race condition is called ``the lost wakeup
problem''.
You can avoid it by using a semaphore abstraction, which remembers a signalled
state, or a condition-variable abstraction, which atomically gives up a
critical region lock and waits.
>If it is legal to wake_up processes at interrupt time...is there a chance that
It's essential to be able wake up processes at interrupt time. Otherwise the
machine could not have processes respond to real time inputs, like packets
coming off the network, keystrokes from the keyboard, etc. You could not have a
read() system wake up instantaneously in response to the user pressing Enter at
the console.
>schedule() can be called (since all the processes are runnable after the wake_up
>call) before I exit the interrupt handler ?? What do I do to ensure that it does
>not happen (in case there is a chance that schedule() can be called before I exit
>the interrupt handler) ?
The short answer is that you don't have to worry about that because the
schedule() call is in another context, not in your interrupt.
The long answer is that the scheduler call cannot be *initiated* while you are
in the interrupt handler (unless it is on another processor). That is a
programming error: interrupt handlers simply may not call the scheduler or all
hell breaks loose. However, an in progress call to the scheduler on behalf of
a process may be interrupted. That is fine; the scheduler knows to protect its
own internal critical regions against interrupts.
>Also is it recommended that processes be woken_up in the bottom half than at
>interrupt time...since the bottom_half is executed at a safer time..
No, the bottom half is not executed at a safer time. The bottom half is
*sometimes* executed at a safer time (e.g. from the scheduler), sometimes not
(e.g when returning from a cascade of interrupts). Bottom half callbacks must
be treated with the same caution as interrupts. The only rules is that bottom
half processing does not nest within itself or in the middle of another
interrupt. This provides some assurances under 2.0 kernels and earlier, though
I'm a little hazy as to what exactly happens on SMP.
On 2.0 kernels, and earlier, it was possible for a process to guard against
bottom half simply by incrementing intr_count before the protected code and
then decrementing it afterward. The start_bh_atomic() and end_bh_atomic()
macros did just that. They do something bletcherous now under SMP, I suspect,
not unlike the emulation of cli() and sti().
------------------------------
From: Robert Schiele <[EMAIL PROTECTED]>
Subject: Re: bz2 file
Date: Thu, 27 Apr 2000 08:31:23 +0200
kartika garg wrote:
>
> Can you not download .bz2 files to windows.I have noticed that when I
> download .bz2 files to windows and than ftp it to linux it gives an
> error--"files are probably corrupt" but if I download them on linux then
> there is no problem. Can somebody tell me the reason???
Assure, your ftp client is set to binary mode!
The Windows ftp client is normaly set to ascii mode which will corrupt
binary code.
Robert
--
Robert Schiele mailto:[EMAIL PROTECTED]
Tel./Fax: +49-621-10059 http://webrum.uni-mannheim.de/math/rschiele/
------------------------------
From: Jan-Willem Stroeken <[EMAIL PROTECTED]>
Crossposted-To: fa.linux.kernel,linux.dev.kernel,linux.redhat.devel
Subject: help: timer freezes after write in driver
Date: Thu, 27 Apr 2000 09:01:24 +0200
I'm writing a driver for a self-made IO-board. All goes well untill a
(software) reset of the board. I've been able to trace that timer(0)
doesn't receive any more interrrupts, the rest seems to be working.
My question : how can my writes to h.w. affect the standard timer (seems
they're not even close in IO-space) How can I trace this problem ???
regards,
Jan-Willem Stroeken
below an excerpt of the 'guily code', the contents of /proc/ioports and
/proc/interrupts
USHORT Reset_DP1(PDATA pDATA)
{
unsigned short i;
ULONG ulTmp;
EnterFunction("Reset_DP1");
DPLOG("reading and writing from/to 0x%x and
0x%x\n",pDATA->us9080BaseAddress,
pDATA->us9080BaseAddress + PCI_CNTRL); /* PCI_CNTRL = 0x0C */
ulTmp = inl(pDATA->us9080BaseAddress + PCI_CNTRL);
ulTmp |= CNTRL_SOFT_RESET;
outl(pDATA->us9080BaseAddress + PCI_CNTRL, ulTmp);
udelay(1000);
ulTmp &= ~CNTRL_SOFT_RESET;
outl(pDATA->us9080BaseAddress + PCI_CNTRL, ulTmp);
udelay(1000);
LeaveFunction("Reset_DP1");
return (0);
}
/proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
02f8-02ff : serial(auto)
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
cc00-cc7f : eth0
d800-d80b : DP1 FPGA
dc00-dcff : DP1 9080
ffa0-ffa7 : ide0
/proc/interrupts
CPU0
0: 6023841 XT-PIC timer
1: 3913 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 745 XT-PIC serial
9: 0 XT-PIC dp1
11: 216011 XT-PIC eth0
12: 318 XT-PIC PS/2 Mouse
13: 1 XT-PIC fpu
14: 120788 XT-PIC ide0
NMI: 0
ERR: 0
--
The notion of a "record" is an obsolete remnant of the days of the
80-column
card.
-- Dennis M. Ritchie
__________________________________________________________
Oc�-Technologies B.V. name : Jan-Willem Stroeken
P.O. Box 101 department : DVS, R&D
5900 MA Venlo e-mail : [EMAIL PROTECTED]
The Netherlands www : http://www.oce.com
Directdial: +31 (0)77 359 58 89
Fax: +31 (0)77 359 53 37
__________________________________________________________
this signature is automagically generated using 'fortune'
------------------------------
** 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
******************************
