Re: Current status of NTFS support
I have installed a Win2000 and you do not have to switch to NTFS. W2000 can be installed on a FAT32 partition. I have installed it on a FAT32 partition and hasn't caused me any problems. You might wanna give it a try. good luck, /me On Fri, 20 Apr 2001 [EMAIL PROTECTED] wrote: > > > Where does write support for NTFS stand at the moment? I noticed that it's > still marked "Dangerous" in the kernel configuration. This is important to me > because it looks like I'll have to start using it next week. My office laptop > is going to be "upgraded" from Windows 98 to 2000. Of course, I hardly ever > boot into Windows any more since installing a Linux partition last year. But > our corporate email standard forces me to use Lotus Notes, which I run under > Wine. The Notes executables and databases are installed on my Windows > partition. The upgrade, though, will involve wiping the hard drive, allocating > the whole drive to a single NTFS partition, and reinstalling Notes after > installing Windows 2000 . That means bye-bye FAT32 partition and hello NTFS. I > can't mount it read-only because I'll still have to update my Notes databases > from Linux. So how risky is this? > > Also, I'll have to recreate my Linux partitions after the upgrade. Does anyone > know if FIPS can split a partition safely that was created under Windows > 2000/NT? It worked fine for Windows 98, but I'm a little worried about what > might happen if I try to use it on an NTFS partition. > > I'd appreciate any advice or help anyone can give me. There's just no way I can > stand going back to using anything but Linux for my daily work. > > Wayne > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
A question about MMX.
I have a Intel Pentium MMX machine and it acts as a mailserver, webserver, ftp and I use X on it. I would like to know if the MMX instructions are used by the kernel in this operations or not (networking, X etc.). Thank you, /me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A question about MMX.
Thank you all who have responded my question. Have a nice day! /me On Sat, 21 Apr 2001, Alan Cox wrote: > > I have a Intel Pentium MMX machine and it acts as a mailserver, webserver, > > ftp and I use X on it. I would like to know if the MMX instructions are > > used by the kernel in this operations or not (networking, X etc.). > > In almost all cases - no. The MMX instructions are mostly not useful. A few > graphics operations benefit from them such as mpeg players but that is about > it. > > On the AMD and Cyrix machines 3Dnow is used extensively by Mesa (3D) and by > many of the mp3 players. The winchip and athlon kernels also use mmx for > block copies but this isnt a win in the pentium case. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CPRM copy protection for ATA drives
I read this article on theregister today: http://www.theregister.co.uk/content/2/15620.html Does anyone have any details on this? I presume that the drive firmware is capable of identifying copy-protected data during a write. I also presume that nobody on lkml would condone such a terrible idea. I imagine that this system is pretty easy to defeat if you can modify the filesystem. Perhaps even a ROT13 modification to ext2 would be sufficient? The consequences of being able to corrupt other people's backups by introducing "copy-protected" data are intriguing... Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
CUV4X-D lockup on boot
I have an ASUS CUV4X-D Dual Processor Mainboard based on a VIA
694XDP chipset. I notice from the archives that someone else
has also reported a lockup with the m/b when using two cpus
and have some info that may be useful to track it down.
Using kernel 2.4.5 the kernel locks up sporadically at boot
time. When I enable the NMI watchdog it occasionally gets
enabled prior to the lockup and perhaps can be useful for
debugging the problem. Here's what happens:
I typed this in, so there may be typos:
..TIMER: vector=49 pin1=2 pin2=0
activating NMI Watchdog ... done.
[locks up here, or before activating NMI watchdog]
[this normally happens next but not in this case
number of MP IRQ sources: 21.
number of IO-APIC #2 registers: 24.
testing the IO APIC...
]
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU : 1
EIP: 0010:[]
EFLAGS: 0246
eax: ebx: ecx: 0001 edx: 0001
esi: edi: ebp: esp: cfff5fa4
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage = cfff5000)
Stack: c0235e8f 0001 0002 c0235eaa
0019 c1442000 2700 b00f
000d 000e c00bcf60 c0172029
Call Trace: []
Code: 85 c0 74 bf 00 e0 ff ff 21 e7 31 f6 bd 10 00 00 00 31 db
Console shuts up ...
[ksymoops output]
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not
found in System.map. Ignoring ksyms_base entry
activating NMI Watchdog ... done.
[locks up here, or before activating NMI watchdog]
NMI Watchdog detected LOCKUP on CPU1, registers:
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 0246
eax: ebx: ecx: 0001 edx: 0001
esi: edi: ebp: esp: cfff5fa4
ds: 0018 es: 0018 ss: 0018
Stack: c0235e8f 0001 0002 c0235eaa
0019 c1442000 2700 b00f
000d 000e c00bcf60 c0172029
Call Trace: []
Code: 85 c0 74 bf 00 e0 ff ff 21 e7 31 f6 bd 10 00 00 00 31 db
>>EIP; c0235cdb<=
Trace; c0172029
Code; c0235cdb
<_EIP>:
Code; c0235cdb<=
0: 85 c0 test %eax,%eax <=
Code; c0235cdd
2: 74 bf je ffc3 <_EIP+0xffc3> c0235c9e
Code; c0235cdf
4: 00 e0 add%ah,%al
Code; c0235ce1
6: ff(bad)
Code; c0235ce2
7: ff 21 jmp*(%ecx)
Code; c0235ce4
9: e7 31 out%eax,$0x31
Code; c0235ce6
b: f6 bd 10 00 00 00 idiv 0x10(%ebp),%al
Code; c0235cec
11: 31 db xor%ebx,%ebx
2 warnings issued. Results may not be reliable.
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping: 6
cpu MHz : 937.557
cache size : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 mmx fxsr sse
bogomips: 1867.77
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping: 6
cpu MHz : 937.557
cache size : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 mmx fxsr sse
bogomips: 1874.32
If this doesn't make someone go "aha!" then I can set up a serial
port for debugging and repeat this a few times.
Thanks,
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CUV4X-D lockup on boot
Further information:
I inserted some printk()s in arch/i386/kernel/smpboot.c
320 static void __init synchronize_tsc_ap (void)
321 {
322 int i;
323
324 /*
325* smp_num_cpus is not necessarily known at the time
326* this gets called, so we first wait for the BP to
327* finish SMP initialization:
328*/
329 printk("ap %d\n", __LINE__);
330 while (!atomic_read(&tsc_start_flag)) mb();
331 printk("ap %d\n", __LINE__);
332
333 for (i = 0; i < NR_LOOPS; i++) {
334 atomic_inc(&tsc_count_start);
335 printk("ap %d\n", __LINE__);
...
When the kernel locks up it does so after line 329 is printk'd
However, on a successful boot it behaves as follows:
...
Intel machine check reporting enabled on CPU#1.
CPU: After vendor init, caps: 0383fbff
CPU: After generic, caps: 0383fbff
CPU: Common caps: 0383fbff
ap 329
OK.
CPU1: Intel Pentium III (Coppermine) stepping 06
CPU has booted.
Before bogomips.
Total of 2 processors activated (3742.10 BogoMIPS).
Before bogocount - setting activated=1.
Boot done.
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
Synchronizing Arb IDs.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-10, 2-13, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=49 pin1=2 pin2=0
activating NMI Watchdog ... done.
number of MP IRQ sources: 21.
number of IO-APIC #2 registers: 24.
testing the IO APIC...
IO APIC #2..
register #00: 0200
...: physical APIC id: 02
register #01: 00178011
... : max redirection entries: 0017
... : IO APIC version: 0011
WARNING: unexpected IO-APIC, please mail
to [EMAIL PROTECTED]
register #02:
... : arbitration: 00
IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 003 03 011 1 11131
01 003 03 000 0 01139
02 003 03 000 0 01131
03 003 03 000 0 01141
04 003 03 000 0 01149
05 003 03 000 0 01151
06 003 03 000 0 01159
07 003 03 000 0 01161
08 003 03 000 0 01169
09 003 03 000 0 01171
0a 000 00 100 0 00000
0b 003 03 000 0 01179
0c 003 03 000 0 01181
0d 000 00 100 0 00000
0e 003 03 000 0 01189
0f 003 03 000 0 01191
10 003 03 110 1 01199
11 003 03 110 1 011A1
12 003 03 110 1 011A9
13 003 03 110 1 011B1
14 000 00 100 0 00000
15 000 00 100 0 00000
16 000 00 100 0 00000
17 000 00 100 0 00000
IRQ to pin mappings:
IRQ0 -> 0-> 2
IRQ1 -> 1
IRQ3 -> 3
IRQ4 -> 4
IRQ5 -> 5
IRQ6 -> 6
IRQ7 -> 7
IRQ8 -> 8
IRQ9 -> 9
IRQ11 -> 11
IRQ12 -> 12
IRQ14 -> 14
IRQ15 -> 15
IRQ16 -> 16
IRQ17 -> 17
IRQ18 -> 18
IRQ19 -> 19
done.
calibrating APIC timer ...
. CPU clock speed is 937.5342 MHz.
. host bus clock speed is 133.9332 MHz.
cpu: 0, clocks: 1339332, slice: 446444
CPU0
cpu: 1, clocks: 1339332, slice: 446444
CPU1
checking TSC synchronization across CPUs: ap 331
ap 335
ap 337
ap 340
ap 345
ap 347
ap 335
ap 337
ap 340
ap 345
ap 347
ap 335
ap 337
ap 340
ap 345
ap 347
ap 335
ap 337
ap 340
ap 345
ap 347
ap 335
ap 337
ap 340
ap 345
ap 347
BIOS BUG: CPU#0 improperly initialized, has -16 usecs TSC skew! FIXED.
BIOS BUG: CPU#1 improperly initialized, has 16 usecs TSC skew! FIXED.
Setting commenced=1, go go go
...
A notable difference is:
Synchronizing Arb IDs.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-10, 2-13, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=49 pin1=2 pin2=0
activating NMI Watchdog ... done.
whereas in a lockup the following occurs:
Synchronizing Arb IDs.
..TIMER: vector=49 pin1=2 pin2=0
activating NMI Watchdog ... done.
i.e. before the init IO_APIC IRQs
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: Ignoring blocked signals in 2.6 / 2.4
Hi,
I have a question regarding blocked signals:
Is the current implementation to ignore attempts to set SIG_IGN on
blocked signals correct?
The following code will go into an endless loop on kernels 2.6.10 and
2.4.25, which is IMHO not the behaviour one would expect.
#include
#include
#include
volatile int sig_received = 0;
void sigio_handler_ex (int signum, siginfo_t * siginfo, void * ucontext)
{
struct sigaction sigio_action;
sig_received++;
printf("handler %d\n",sig_received);
sigio_action.sa_handler = SIG_IGN;
sigio_action.sa_flags = 0;
sigemptyset(&sigio_action.sa_mask);
sigaction (SIGIO, &sigio_action, 0);
kill(getpid(),SIGIO);
sigio_action.sa_sigaction = sigio_handler_ex;
sigio_action.sa_flags = SA_SIGINFO;
sigemptyset(&sigio_action.sa_mask);
sigaction (SIGIO, &sigio_action, 0);
}
int main(int argc, char **argv) {
struct sigaction sigio_action;
sigio_action.sa_sigaction = sigio_handler_ex;
sigio_action.sa_flags = SA_SIGINFO;
sigemptyset(&sigio_action.sa_mask);
sigaction (SIGIO, &sigio_action, 0);
kill(getpid(),SIGIO);
while (! sig_received) {
printf("waiting for signal\n");
sleep(1);
}
kill(getpid(),SIGIO);
printf("%d signals handled\n",sig_received);
}
In kernel 2.6.10/kernel/signal.c sig_ignored() I found this comment:
...
/*
* Blocked signals are never ignored, since the
* signal handler may change by the time it is
* unblocked.
*/
if (sigismember(&t->blocked, sig))
return 0;
...
so it seems this behaviour is intentional, but I don't understand
it. Why should it matter if a signal handler may change while blocked,
if it is ignored also, which is a user request?
The machine im writing this mail on runs with the above lines
commented out without any problems so far...
All this resulted from problems a customer had with implementing a
whole protocol-stack to a serially attached device in a
signal-handler. After the handler ran (with SIG_IGN) there was always
an extra SIGIO which triggered the handler again. Of course the real
fix was to move the protocol-stack out of the handler but still it
should have worked since it was a controlled environment (so there
wasn't even a race between entering the handler and setting
SIG_IGN). Oh and it worked for years under some realtime variant of
hp-unix.
Please be so kind and CC any answer to me directly since im
currently not subscribed to lkm.
Yours
Tobias Grundmann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: Ignoring blocked signals in 2.6 / 2.4 not possible
Hi,
I have a question regarding blocked signals:
Is the current implementation to ignore attempts to set SIG_IGN on
blocked signals correct?
The following code will go into an endless loop on kernels 2.6.10 and
2.4.25, which is IMHO not the behaviour one would expect.
#include
#include
#include
volatile int sig_received = 0;
void sigio_handler_ex (int signum, siginfo_t * siginfo, void * ucontext)
{
struct sigaction sigio_action;
sig_received++;
printf("handler %d\n",sig_received);
sigio_action.sa_handler = SIG_IGN;
sigio_action.sa_flags = 0;
sigemptyset(&sigio_action.sa_mask);
sigaction (SIGIO, &sigio_action, 0);
kill(getpid(),SIGIO);
sigio_action.sa_sigaction = sigio_handler_ex;
sigio_action.sa_flags = SA_SIGINFO;
sigemptyset(&sigio_action.sa_mask);
sigaction (SIGIO, &sigio_action, 0);
}
int main(int argc, char **argv) {
struct sigaction sigio_action;
sigio_action.sa_sigaction = sigio_handler_ex;
sigio_action.sa_flags = SA_SIGINFO;
sigemptyset(&sigio_action.sa_mask);
sigaction (SIGIO, &sigio_action, 0);
kill(getpid(),SIGIO);
while (! sig_received) {
printf("waiting for signal\n");
sleep(1);
}
kill(getpid(),SIGIO);
printf("%d signals handled\n",sig_received);
}
In kernel 2.6.10/kernel/signal.c sig_ignored() I found this comment:
...
/*
* Blocked signals are never ignored, since the
* signal handler may change by the time it is
* unblocked.
*/
if (sigismember(&t->blocked, sig))
return 0;
...
so it seems this behaviour is intentional, but I don't understand
it. Why should it matter if a signal handler may change while blocked,
if it is ignored also, which is a user request?
The machine im writing this mail on runs with the above lines
commented out without any problems so far...
All this resulted from problems a customer had with implementing a
whole protocol-stack to a serially attached device in a
signal-handler. After the handler ran (with SIG_IGN) there was always
an extra SIGIO which triggered the handler again. Of course the real
fix was to move the protocol-stack out of the handler but still it
should have worked since it was a controlled environment (so there
wasn't even a race between entering the handler and setting
SIG_IGN). Oh and it worked for years under some realtime variant of
hp-unix.
Please be so kind to CC any answer to me directly since I'm
currently not subscribed to lkml.
Yours
Tobias Grundmann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: When the FUD is all around (sniff).
> Interesting. . . > > What country is that? What is it about the computer that won't allow it to > run things other than Windows - or is the TV just mistaken (I suspect so)? You don't want to know the country. Yeap, you're right. They are all just a bunch of morons. > > > Richard Schilling > > -Original Message- > From: lk [mailto:[EMAIL PROTECTED]] > > > Speaking of: > > A TV station in my country said that the most pirated products belong to > > M$ because computers cannot work wothout the GUI M$ windows provides. > > > In my country about 75% percent of M$ software are illegal copies :) > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: directory order of files
on reiserfs ls -U show soething like: one two four three On Fri, 29 Jun 2001, Edmund GRIMLEY EVANS wrote: > With Linux ext2, and some other systems, when you create files in a > new directory, the file system remembers their order: > > $ mkdir new > $ cd new > $ touch one two three four > $ ls -U > one two three four > > (1) Is there any standard that says a system should behave this way? > Is there any software that depends on this behaviour? > > (2) Are there Linux file systems that don't work this way? Maybe > someone with a mounted writable reiserfs could do a quick check. > > Please copy replies to me as I am not subscribed. Thanks. > > Edmund > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: When the FUD is all around (sniff).
Speaking of: A TV station in my country said that the most pirated products belong to M$ because computers cannot work wothout the GUI M$ windows provides. In my country about 75% percent of M$ software are illegal copies :) > > I suppose they received some pression from M$, but if people read of a FUD > > from a M$ employed, then they can guess what is going on, if it is a > > newspaper usually telling facts in a correct way... > > It is common for newspaper staff to be corrupt, same with magazine people. > Sometimes because people generally believe in a cause and are not impartial > (which I've seen both pro and anti Linux btw) and sometimes because advertising > revenue is a good thing. > > > The situation is going to be sad > > There is a saying in he UK 'You can fool all of the people some of the time, > you can fool some of the people all the time, but you cannot fool all of the > people all of the time'. You only have to look at the incredibly dim view > technical people take of most printed reviews to see that. > > Alan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Timers to threads
If u search for usleep in google then first document says that usleep will
have max range of 1,000,000 microseconds as the max sleep delay and
after the delay time expires the actual execution may get delayed because
of high system activity.
If you are writing kernel modules, you may use schedule_timeout().
schedule_timeout() uses dynamic timers and when schedule( ) is invoked,
another process
is selected for execution; when the former process resumes its execution,
the function
schedule_timeout removes the dynamic timer.
code snippet
for(;;){
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(unsigned long timeout); /* schedule_timeout(10*HZ) will
suspend process & resume execution after 10 seconds */
set_current_state(TASK_RUNNING);
}
hope it helps
regards
lk
- Original Message -
From: "Banu R Reefath" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, March 30, 2005 10:22 PM
Subject: Timers to threads
> Dear Sir/Mam
> We are using Linux in one of our embedded products.This is the first
time we are working in this Platform.We have few doubts regarding
implementing s/w timers & how to pass the timer interrupts to threads .
> In net we coudnt find exactly what we want .Could you please help us in
this regard?
>
> Ideas from us
> 1. If we want a thread to execute at particular intervals should it be
done only through
> usleep() system call ? Will it be accurate enough ?
> Because it is a real time design for a Medical Product.
>
> 2. If we use kernel timers to invoke at particular time intervals using
add_timer () how to pass on to the application that the time has elapsed?
>
> A piece of code demonstartion would be much more helpful to us
>
> Thanks & Regards,
> Reefath Banu Rajali
> Software Engineer
> Larsen & Toubro
> Embedded Systems & Software
> Mysore
> India
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux virtual memory manager
The try_to_swap_out( ) function attempts to free a given page frame, either discarding or swapping out its contents. It will add the page to swap and remove the entry from page table of page cache. In 2.6.x series you can look into shrink_list() function which is called from kswapd daemon. The function you are trying to look for an equivalent of try_to_swap_out() is add_to_swap() and after that try_to_unmap() which will add the page of page cache to swap cache and remove entry from the page table respectively. regards lk - Original Message - From: "Josef E. Galea" <[EMAIL PROTECTED]> To: Sent: Thursday, March 31, 2005 6:31 AM Subject: Linux virtual memory manager > Hi, > > Can someone point me to a document explaining the differences between > the 2.4 and the 2.6 virtual memory manager. Particularly I am looking > for the function/s that replaces the try_to_swap_out() in the 2.6.x > series of kernels. > > Thanks > Josef > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: whats happening
On Sat, 23 Dec 2000, Sourav Sen wrote: > In some parts of the kernel code I find expression like > > len = (len + ~PAGE_MASK) & PAGE_MASK ; > > Whats happening to len? It's being aligned properly. if you have a continuous array of objects that are each 8 bytes, you create a mask that's FFF8, then if len=7, instead of doing an operation on the last byte of the first thing and the first 7 bytes of the second, the above expression will add 7, making len 14, then normalize it to the last valid object address, 8. And if you start with a valid address, you get that same address back. justin -- To summon a demon you must first know its name. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
