The most noticeable part of this is that the run_task_queue fix should
cure the lockup that some people have seen.
The shmfs cleanup should be unnoticeable except to users who use SAP with
huge shared memory segments, where Christoph Rohlands work not only
makes the code much more readable, it should also make it dependable..
Linus
----
- pre3:
- Christian Jullien: smc9194: proper dev_kfree_skb_irq
- Cort Dougan: new-style PowerPC Makefiles
- Andrew Morton, Petr Vandrovec: fix run_task_queue
- Christoph Rohland: shmfs for shared memory handling
- pre2:
- Kai Germaschewski: ISDN update (including Makefiles)
- Jens Axboe: cdrom updates
- Petr Vandrovec; Matrox G450 support
- Bill Nottingham: fix FAT32 filesystems on 64-bit platforms
- David Miller: sparc (and other) Makefile fixup
- Andrea Arkangeli: alpha SMP TLB context fix (and cleanups)
- Niels Kristian Bech Jensen: checkconfig, USB warnings
- Andrew Grover: large ACPI update
- pre1:
- me: drop support for old-style Makefiles entirely. Big.
- me: check b_end_io at the IO submission path
- me: fix "ptep_mkdirty()" (so that swapoff() works correctly)
- fix fault case in copy_from_user() with a constant size, where
((size & 3) == 3)
With CONFIG_DRM_R128=m
we fail to produce module linux/drivers/char/drm/r128.o
Any thoughts.
Albert
Linus Torvalds wrote:
>
> The most noticeable part of this is that the run_task_queue fix should
> cure the lockup that some people have seen.
>
> The shmfs cleanup should be unnoticeable except to users who use SAP with
> huge shared memory segments, where Christoph Rohlands work not only
> makes the code much more readable, it should also make it dependable..
>
> Linus
>
> ----
>
> - pre3:
> - Christian Jullien: smc9194: proper dev_kfree_skb_irq
> - Cort Dougan: new-style PowerPC Makefiles
> - Andrew Morton, Petr Vandrovec: fix run_task_queue
> - Christoph Rohland: shmfs for shared memory handling
>
--
Albert Cranford Deerfield Beach FL USA
[email protected]
Similar problem here - with CONFIG_DRM_TDFX=m
I have not gotten a tdfx.o module complied since the
start of the test13-pre series...
So no quake 3 arena unless I want to play at < 1 fps...
:(
jjs
Albert Cranford wrote:
> With CONFIG_DRM_R128=m
> we fail to produce module linux/drivers/char/drm/r128.o
[Albert Cranford]
> With CONFIG_DRM_R128=m
> we fail to produce module linux/drivers/char/drm/r128.o
He's right. Linus, please apply.
Peter
--- test13pre3/drivers/char/Makefile.orig Wed Dec 13 23:56:01 2000
+++ test13pre3/drivers/char/Makefile Sun Dec 17 23:55:00 2000
@@ -25,6 +25,7 @@
misc.o pty.o random.o selection.o serial.o \
tty_io.o
+mod-subdirs := joystick ftape drm pcmcia
list-multi :=
KEYMAP =defkeymap.o
On Mon, 18 Dec 2000, J Sloan wrote:
> Similar problem here - with CONFIG_DRM_TDFX=m
> I have not gotten a tdfx.o module complied since the
> start of the test13-pre series...
>
> So no quake 3 arena unless I want to play at < 1 fps...
>
Does this patch fix your problem?
--- test13-pre3/drivers/char/Makefile Mon Dec 18 01:21:31 2000
+++ linux/drivers/char/Makefile Mon Dec 18 06:58:06 2000
@@ -16,6 +16,8 @@
O_TARGET := char.o
+mod-subdirs := drm
+
obj-y += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o
# All of the (potential) objects that export symbols.
--
Niels Kristian Bech Jensen -- [email protected] -- http://www.image.dk/~nkbj/
----------->> Stop software piracy --- use free software! <<-----------
Niels Kristian Bech Jensen wrote:
> Does this patch fix your problem?
>
> --- test13-pre3/drivers/char/Makefile Mon Dec 18 01:21:31 2000
> +++ linux/drivers/char/Makefile Mon Dec 18 06:58:06 2000
> @@ -16,6 +16,8 @@
>
> O_TARGET := char.o
>
> +mod-subdirs := drm
> +
> obj-y += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o
>
Some progress anyway;
The module now compiles and gets installed -
Unfortunately, attempting to load it does not go well:
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
remap_page_range
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
__wake_up
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
mtrr_add
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
__generic_copy_from_user
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
schedule
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
kmalloc
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
si_meminfo
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
create_proc_entry
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
inter_module_put
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
__get_free_pages
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
boot_cpu_data
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
inter_module_get
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
remove_wait_queue
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
high_memory
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
iounmap
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
free_pages
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
__ioremap
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
del_timer
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
interruptible_sleep_on
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
__pollwait
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
kfree
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
remove_proc_entry
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
pci_find_slot/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o:
unresolved symbol
kill_fasync
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
fasync_helper
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
add_wait_queue
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
do_mmap_pgoff
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
mem_map
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
sprintf
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
jiffies
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
printk
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
add_timer
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved
symbol
__generic_copy_to_user
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: insmod
/lib/modul
es/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o failed
/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: insmod tdfx
failed
[J Sloan]
> The module now compiles and gets installed -
> Unfortunately, attempting to load it does not go well:
>
> kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
> kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up
> kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add
> kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user
> kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule
> kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc
> kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo
Those symbols are rather generic and rather important. Sounds like a
generic module problem. Do other modules load? Does your kernel use
MODVERSIONS? (This module apparently doesn't.) Are you using a recent
version of modutils?
Puzzled. Maybe Keith Owens knows something.
Peter
Hi,
What is this change about?
diff -u --recursive --new-file v2.4.0-test12/linux/arch/i386/kernel/smpboot.c linux/arch/i386/kernel/smpboot.c
--- v2.4.0-test12/linux/arch/i386/kernel/smpboot.c Mon Dec 11 17:59:43 2000
+++ linux/arch/i386/kernel/smpboot.c Thu Dec 14 14:54:40 2000
@@ -694,6 +694,11 @@
apic_write_around(APIC_ICR, APIC_DM_STARTUP
| (start_eip >> 12));
+ /*
+ * Give the other CPU some time to accept the IPI.
+ */
+ udelay(300);
+
Dprintk("Startup point 1.\n");
Dprintk("Waiting for send to finish...\n");
There is the following code is just after it, making the above change
just useless garbage:
timeout = 0;
do {
Dprintk("+");
udelay(100);
send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
} while (send_status && (timeout++ < 1000));
/*
* Give the other CPU some time to accept the IPI.
*/
udelay(200);
If we need 600usecs of delay for certain systems, then why not just make
it like below?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
patch-2.0.4-test13-pre3-startup_ipi-0
diff -up --recursive --new-file linux-2.4.0-test13-pre3.macro/arch/i386/kernel/smpboot.c linux-2.4.0-test13-pre3/arch/i386/kernel/smpboot.c
--- linux-2.4.0-test13-pre3.macro/arch/i386/kernel/smpboot.c Mon Dec 18 12:14:10 2000
+++ linux-2.4.0-test13-pre3/arch/i386/kernel/smpboot.c Mon Dec 18 12:15:49 2000
@@ -694,11 +694,6 @@ static void __init do_boot_cpu (int apic
apic_write_around(APIC_ICR, APIC_DM_STARTUP
| (start_eip >> 12));
- /*
- * Give the other CPU some time to accept the IPI.
- */
- udelay(300);
-
Dprintk("Startup point 1.\n");
Dprintk("Waiting for send to finish...\n");
@@ -712,7 +707,7 @@ static void __init do_boot_cpu (int apic
/*
* Give the other CPU some time to accept the IPI.
*/
- udelay(200);
+ udelay(500);
/*
* Due to the Pentium erratum 3AP.
*/
In article <[email protected]> you write:
> [J Sloan]
> > The module now compiles and gets installed -
> > Unfortunately, attempting to load it does not go well:
> >
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
>...
> Those symbols are rather generic and rather important. Sounds like a
> generic module problem. Do other modules load? Does your kernel use
> MODVERSIONS? (This module apparently doesn't.) Are you using a recent
> version of modutils?
The most important question: Did you run "make dep" after doing the patch?
Olaf
Hi Linus,
On Sun, 17 Dec 2000, Linus Torvalds wrote:
> The shmfs cleanup should be unnoticeable except to users who use SAP
> with huge shared memory segments, where Christoph Rohlands work not
> only makes the code much more readable, it should also make it
> dependable..
:-)
The appended patch fixes the following:
1) We cannot unlock the page in shmem_writepage on ooswap since
page_launder will do this later.
2) We should set the inode number of SYSV segments to the (user) shmid
and not the internal id.
Greetings
Christoph
diff -uNr 4-13-3/mm/shmem.c c/mm/shmem.c
--- 4-13-3/mm/shmem.c Mon Dec 18 15:08:32 2000
+++ c/mm/shmem.c Mon Dec 18 15:13:10 2000
@@ -210,37 +210,39 @@
{
int error;
struct shmem_inode_info *info;
- swp_entry_t *entry;
+ swp_entry_t *entry, swap;
info = &((struct inode *)page->mapping->host)->u.shmem_i;
if (info->locked)
return 1;
- spin_lock(&info->lock);
- entry = shmem_swp_entry (info, page->index);
- if (!entry) /* this had been allocted on page allocation */
- BUG();
- error = -EAGAIN;
- if (entry->val)
- goto out;
-
/*
* 1 means "cannot write out".
* We can't drop dirty pages
* just because we ran out of
* swap.
*/
- error = 1;
- *entry = __get_swap_page(2);
- if (!entry->val)
+ swap = __get_swap_page(2);
+ if (!swap.val)
+ return 1;
+
+ spin_lock(&info->lock);
+ entry = shmem_swp_entry (info, page->index);
+ if (!entry) /* this had been allocted on page allocation */
+ BUG();
+ error = -EAGAIN;
+ if (entry->val) {
+ __swap_free(swap, 2);
goto out;
+ }
+ *entry = swap;
error = 0;
/* Remove the from the page cache */
lru_cache_del(page);
remove_inode_page(page);
/* Add it to the swap cache */
- add_to_swap_cache(page,*entry);
+ add_to_swap_cache(page, swap);
page_cache_release(page);
SetPageDirty(page);
info->swapped++;
diff -uNr 4-13-3/ipc/shm.c c/ipc/shm.c
--- 4-13-3/ipc/shm.c Mon Dec 18 15:08:32 2000
+++ c/ipc/shm.c Mon Dec 18 15:13:58 2000
@@ -220,7 +220,7 @@
shp->shm_segsz = size;
shp->id = shm_buildid(id,shp->shm_perm.seq);
shp->shm_file = file;
- file->f_dentry->d_inode->i_ino = id;
+ file->f_dentry->d_inode->i_ino = shp->id;
file->f_op = &shm_file_operations;
shm_tot += numpages;
shm_unlock (id);
On 18 Dec 00 at 13:58, Maciej W. Rozycki wrote:
> What is this change about?
>
> diff -u --recursive --new-file v2.4.0-test12/linux/arch/i386/kernel/smpboot.c linux/arch/i386/kernel/smpboot.c
> --- v2.4.0-test12/linux/arch/i386/kernel/smpboot.c Mon Dec 11 17:59:43 2000
> +++ linux/arch/i386/kernel/smpboot.c Thu Dec 14 14:54:40 2000
> @@ -694,6 +694,11 @@
> apic_write_around(APIC_ICR, APIC_DM_STARTUP
> | (start_eip >> 12));
>
> + /*
> + * Give the other CPU some time to accept the IPI.
> + */
> + udelay(300);
> +
> Dprintk("Startup point 1.\n");
>
> Dprintk("Waiting for send to finish...\n");
>
> There is the following code is just after it, making the above change
> just useless garbage:
No. Without udelay() before first printk() it just does not boot on my
motherboard. There were two choices: either remove all printk() from
these loops (define Dprintk to null), or add udelay(x), where x >= 200,
before first printk. I sent patch twice to linux-kernel, and to
[email protected], and nobody said anything against it.
> timeout = 0;
> do {
> Dprintk("+");
> udelay(100);
> send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
> } while (send_status && (timeout++ < 1000));
>
> /*
> * Give the other CPU some time to accept the IPI.
> */
> udelay(200);
>
> If we need 600usecs of delay for certain systems, then why not just make
> it like below?
No. If there is no udelay() before first printk(), on my GA-6VXD7 board
(SMP VIA 694X) only 'Startup point 1.' is printed, but no 'Waiting
for send to finish...'. So maybe we do not need udelay(200) below loop,
but for sure we need udelay() before first printk(). (my board works
without ANY udelay() in smpboot.c, except one I added... This one is
required.) If somebody lives in Prague, and wants to come with logical
analyzer (or if I should come with motherboard), I'm willing to continue
testing. But current idea is that inb/outb done by cursor positioning
code is incompatible with something else done in secondary CPU startup.
(it boots also without any kernel change with 'console=ttyS0,9600', but
it may be caused by slow serial line)
Without delay() both CPU die, and board does not react to anything except
hard reset anymore (and sometime it does not react even to hard reset; lookup
for my messages during last week).
Best regards,
Petr Vandrovec
[email protected]
On Mon, 18 Dec 2000, Petr Vandrovec wrote:
> No. Without udelay() before first printk() it just does not boot on my
> motherboard. There were two choices: either remove all printk() from
> these loops (define Dprintk to null), or add udelay(x), where x >= 200,
> before first printk. I sent patch twice to linux-kernel, and to
> [email protected], and nobody said anything against it.
I see. But are you sure this is the right fix? You may be covering
the real problem with this arbitrary delay.
I haven't actually noticed any of your previous mails -- given the load
on the list I sometimes miss letters with "uninteresting" subjects.
> No. If there is no udelay() before first printk(), on my GA-6VXD7 board
> (SMP VIA 694X) only 'Startup point 1.' is printed, but no 'Waiting
> for send to finish...'. So maybe we do not need udelay(200) below loop,
> but for sure we need udelay() before first printk(). (my board works
> without ANY udelay() in smpboot.c, except one I added... This one is
> required.) If somebody lives in Prague, and wants to come with logical
Other delays are imposed by the MPS (most if not all of them). For
example there are systems that assert RESET to a CPU as a result of an
INIT IPI. These systems need these delays to allow CPUs to recover.
> analyzer (or if I should come with motherboard), I'm willing to continue
> testing. But current idea is that inb/outb done by cursor positioning
> code is incompatible with something else done in secondary CPU startup.
Have you tried putting explicit display adapter (other ISA) I/O accesses
after sending the IPI to see if they trigger the problem? IPIs are
transmitted over the inter-APIC bus and should be completely invisible to
other parts of the system. But the code involved in processing a printk()
may interact with the one executed by another CPU right after waking it
up. It would be worth to investigate it...
> (it boots also without any kernel change with 'console=ttyS0,9600', but
> it may be caused by slow serial line)
Or by running different code.
> Without delay() both CPU die, and board does not react to anything except
> hard reset anymore (and sometime it does not react even to hard reset; lookup
> for my messages during last week).
Now THAT is weird. It might mean a chipset bug. Still no idea how an
inter-APIC message might trigger it -- it completely bypasses MB
chipset... Hmm, maybe not... Is your I/O APIC discrete (like Intel's
82093AA) or integrated? It appears there are vendors manufacturing I/O
APIC clones and this may imply new problems, sigh...
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
Hello
Last Saturday I've spent some time on testing deadlock which bites me
for a
long time on my BP6 SMP board (practically since I've started to use
ATA66
controller). Before you will stop reading and saying I should buy a
different
board please try to continue for a few moments. (its a bit longer - but
I think
there are few interesting points)
First I'll describe my hw configuration - BP6 128MB 2x400MHz CPU
(usually running @92MHz FSB - ~560MHz)
Cards: SBLive slot 2, TV-Phone98 slot 5, G400Max AGP
Hard drives: 6GB Western on UDMA33 (contains only vfat partitions),
CD-ROM Ricoh 9060A UDMA33,
30GB IBM UDMA66 hpt366 (contains only ext2 partitions).
There are no shared interrupts in /proc/interrupts.
hdparm gives me around 34MB/s for UDMA66 drive and 8MB/s for WD6GB
drive.
For testing I've used the following simple sequence:
I've created 650MB file on UDMA66 drive and I've been copying this file
to UDMA33 vfat partition.
(while : ; do cp /ext2/my650 /vfat/ ; md5sum /vfat/my650 ; done)
When this test was running correctly for 6 times I've considered it
stable.
Kernel used for testing has been CLEAN UNPATCHED 2.4.0-test12
(with SMP, and without SMP support)
Here are some initial results:
After reboot and running this on console - everything was OK starting
the X
server and not doing anything else in them (e.g. moving mouse) - again
everything was OK.
And now to the less positive part - as soon as I've turned on programs
which are using SBLive or TV card the locking had begun.
After a while I've came with conclusion it doesn't matter if it's just
emu10k1
driver or bttv driver or both of them running at same time - simply when
one or
both of them were running I've been unable to copy the file from UDMA66
to
UDMA33 (test usually occurred after 200MB has been copied).
For the huge amount of tested environment I've used just fbtv and linux
matrox
framebuffer console with just bttv as this was usually to the fastest
way to
deadlock.
For the testings I've flashed around 9 different BP6 bioses (always
cleaning
all the BIOS settings) - LP, NJ, QQbeta, QQ-2, and couple of RU bioses -
usually I'm using ru with htp 1.26 Also I've been checking
non-overclocked &
overclocked setup with each BIOS.
After few hours the clear result was:
Linux kernel with SMP or without SMP ALWAYS locks during this test - it
has
never finished more then 1 copy of this file - and the crash is always
complete
deadlock - but the console says something about hdf: lost interrupt
first - but
I've already reported this and no one seems to care. (I'll repeat - I've
used
all known to me Bioses & correctly clocked CPU for this test and it had
always
failed)
So I've came to conclusion that there could be several possible
problems:
UDMA 4 mode is not correctly programmed for hpt366 controller (as the
only one
who seems to understand the setting for this chipset is Andre itself, I
afraid
that he is the only one who could play with them and possible fix)
UDMA 4 mode is incorrectly programmed and it doesn't take into account
that
some other interrupt services might lock the system bus for a while
(again this
is for Andre Hedrick probably) (I've also noticed few other peoples
comlaing
about some problems while copying huge files - and they didn't have BP6
board,
so maybe its some more general problem)
BP6 hpt366 is completely bad piece of hardware (I hope it's not that
bad)
Ok after this - I've also found some partial solution for this problem
which is
relatively easy - degrading hpt366 from UDMA 4 to UDMA 2 with 'hdparm
-X66
/dev/hdf' - after issuing this command all my test had never failed (8
copies
without any problems while playing TV and mp3 files with xmms) (btw is
there
some way I could turn it back to UDMA 4 mode ??)
So hpt366 & linux could coexists peacefully they just can't use UDMA4
mode.
I've also run this test with both drives on UDMA33 controllers - again
without
a single problem.
So that's probably all I wanted to say - so maybe some advice for BP6
users -
if they want to have stable system - they should probably not use UDMA 4
mode
(-X66 for hpt366 or just ignore UDMA66 controller at all - especially if
you
are using devices which generates a lot of interrupts - like sound
cards, tv
card, network cards :)
And strange note for the end - I had usually problems even to boot the
machine
when it has not been overclocked and it was running with 66MHz FSB speed
-
however this "hdf: lost interrupt" message has not lead to deadlock of
machine
(deadlock means for me that computer doesn't react even to Magic SysRq)
- after
a few messages about the lost interrupts the system has turned off DMA
and was
continuing with boot process however using computer with just 3MB/s
throughput
is not that funny (also there were no APIC error with 66 FSB). This boot
problem has never happened to me while running with 92MHz FSB even
though APIC
errors makes console practically unusable.
I think this letter is already way to long - so now I'm curios
if this will be helpful for anyone....
--
There are three types of people in the world:
those who can count, and those who can't.
Zdenek Kabelac http://i.am/kabi/ [email protected] {debian.org; fi.muni.cz}
Hi Linus,
On 18 Dec 2000, Christoph Rohland wrote:
> The appended patch fixes the following:
>
> 1) We cannot unlock the page in shmem_writepage on ooswap since
> page_launder will do this later.
>
> 2) We should set the inode number of SYSV segments to the (user)
> shmid and not the internal id.
And here additionally is the SYSV detach/destroy logic fixed which
(again) left destroyed shm segments hang around :-(
I also cleaned up the list of included files in ipc/shm.c
Greetings
Christoph
diff -uNr 4-13-3/ipc/shm.c c/ipc/shm.c
--- 4-13-3/ipc/shm.c Mon Dec 18 15:08:32 2000
+++ c/ipc/shm.c Mon Dec 18 20:07:21 2000
@@ -15,23 +15,13 @@
*
*/
-#include <linux/config.h>
-#include <linux/module.h>
#include <linux/malloc.h>
#include <linux/shm.h>
-#include <linux/swap.h>
-#include <linux/smp_lock.h>
#include <linux/init.h>
-#include <linux/locks.h>
#include <linux/file.h>
#include <linux/mman.h>
-#include <linux/vmalloc.h>
-#include <linux/pagemap.h>
#include <linux/proc_fs.h>
-#include <linux/highmem.h>
-
#include <asm/uaccess.h>
-#include <asm/pgtable.h>
#include "util.h"
@@ -109,6 +99,7 @@
BUG();
shp->shm_atim = CURRENT_TIME;
shp->shm_lprid = current->pid;
+ shp->shm_nattch++;
shm_unlock(id);
}
@@ -123,21 +114,14 @@
*
* @shp: struct to free
*
- * It has to be called with shp and shm_ids.sem locked and will
- * release them
+ * It has to be called with shp and shm_ids.sem locked
*/
static void shm_destroy (struct shmid_kernel *shp)
{
- struct file * file = shp->shm_file;
-
- shp->shm_file = NULL;
shm_tot -= (shp->shm_segsz + PAGE_SIZE - 1) >> PAGE_SHIFT;
- shm_unlock (shp->id);
shm_rmid (shp->id);
+ fput (shp->shm_file);
kfree (shp);
- up (&shm_ids.sem);
- /* put the file outside the critical path to prevent recursion */
- fput (file);
}
/*
@@ -158,10 +142,10 @@
BUG();
shp->shm_lprid = current->pid;
shp->shm_dtim = CURRENT_TIME;
- if(shp->shm_flags & SHM_DEST &&
- file_count (file) == 2) /* shp and the vma have the last
- references*/
- return shm_destroy (shp);
+ shp->shm_nattch--;
+ if(shp->shm_nattch == 0 &&
+ shp->shm_flags & SHM_DEST)
+ shm_destroy (shp);
shm_unlock(id);
up (&shm_ids.sem);
@@ -176,7 +160,7 @@
}
static struct file_operations shm_file_operations = {
- mmap: shm_mmap
+ mmap: shm_mmap
};
static struct vm_operations_struct shm_vm_ops = {
@@ -218,9 +202,10 @@
shp->shm_atim = shp->shm_dtim = 0;
shp->shm_ctim = CURRENT_TIME;
shp->shm_segsz = size;
+ shp->shm_nattch = 0;
shp->id = shm_buildid(id,shp->shm_perm.seq);
shp->shm_file = file;
- file->f_dentry->d_inode->i_ino = id;
+ file->f_dentry->d_inode->i_ino = shp->id;
file->f_op = &shm_file_operations;
shm_tot += numpages;
shm_unlock (id);
@@ -370,15 +355,13 @@
struct inode * inode;
shp = shm_get(i);
- if(shp == NULL || shp->shm_file == NULL)
+ if(shp == NULL)
continue;
inode = shp->shm_file->f_dentry->d_inode;
- down (&inode->i_sem);
- *rss += inode->i_mapping->nrpages;
spin_lock (&inode->u.shmem_i.lock);
+ *rss += inode->i_mapping->nrpages;
*swp += inode->u.shmem_i.swapped;
spin_unlock (&inode->u.shmem_i.lock);
- up (&inode->i_sem);
}
}
@@ -462,7 +445,7 @@
tbuf.shm_ctime = shp->shm_ctim;
tbuf.shm_cpid = shp->shm_cprid;
tbuf.shm_lpid = shp->shm_lprid;
- tbuf.shm_nattch = file_count (shp->shm_file) - 1;
+ tbuf.shm_nattch = shp->shm_nattch;
shm_unlock(shmid);
if(copy_shmid_to_user (buf, &tbuf, version))
return -EFAULT;
@@ -512,13 +495,12 @@
goto out_up;
err = shm_checkid(shp, shmid);
if (err == 0) {
- if (file_count (shp->shm_file) == 1) {
+ if (shp->shm_nattch){
+ shp->shm_flags |= SHM_DEST;
+ /* Do not find it any more */
+ shp->shm_perm.key = IPC_PRIVATE;
+ } else
shm_destroy (shp);
- return 0;
- }
- shp->shm_flags |= SHM_DEST;
- /* Do not find it any more */
- shp->shm_perm.key = IPC_PRIVATE;
}
/* Unlock */
shm_unlock(shmid);
@@ -619,13 +601,23 @@
return -EACCES;
}
file = shp->shm_file;
- get_file (file);
+ shp->shm_nattch++;
shm_unlock(shmid);
down(¤t->mm->mmap_sem);
user_addr = (void *) do_mmap (file, addr, file->f_dentry->d_inode->i_size, prot, flags, 0);
up(¤t->mm->mmap_sem);
- fput (file);
+
+ down (&shm_ids.sem);
+ if(!(shp = shm_lock(shmid)))
+ BUG();
+ shp->shm_nattch--;
+ if(shp->shm_nattch == 0 &&
+ shp->shm_flags & SHM_DEST)
+ shm_destroy (shp);
+ shm_unlock(shmid);
+ up (&shm_ids.sem);
+
*raddr = (unsigned long) user_addr;
err = 0;
if (IS_ERR(user_addr))
@@ -684,7 +676,7 @@
shp->shm_segsz,
shp->shm_cprid,
shp->shm_lprid,
- file_count (shp->shm_file) - 1,
+ shp->shm_nattch,
shp->shm_perm.uid,
shp->shm_perm.gid,
shp->shm_perm.cuid,
diff -uNr 4-13-3/mm/shmem.c c/mm/shmem.c
--- 4-13-3/mm/shmem.c Mon Dec 18 15:08:32 2000
+++ c/mm/shmem.c Mon Dec 18 15:13:10 2000
@@ -210,37 +210,39 @@
{
int error;
struct shmem_inode_info *info;
- swp_entry_t *entry;
+ swp_entry_t *entry, swap;
info = &((struct inode *)page->mapping->host)->u.shmem_i;
if (info->locked)
return 1;
- spin_lock(&info->lock);
- entry = shmem_swp_entry (info, page->index);
- if (!entry) /* this had been allocted on page allocation */
- BUG();
- error = -EAGAIN;
- if (entry->val)
- goto out;
-
/*
* 1 means "cannot write out".
* We can't drop dirty pages
* just because we ran out of
* swap.
*/
- error = 1;
- *entry = __get_swap_page(2);
- if (!entry->val)
+ swap = __get_swap_page(2);
+ if (!swap.val)
+ return 1;
+
+ spin_lock(&info->lock);
+ entry = shmem_swp_entry (info, page->index);
+ if (!entry) /* this had been allocted on page allocation */
+ BUG();
+ error = -EAGAIN;
+ if (entry->val) {
+ __swap_free(swap, 2);
goto out;
+ }
+ *entry = swap;
error = 0;
/* Remove the from the page cache */
lru_cache_del(page);
remove_inode_page(page);
/* Add it to the swap cache */
- add_to_swap_cache(page,*entry);
+ add_to_swap_cache(page, swap);
page_cache_release(page);
SetPageDirty(page);
info->swapped++;
Olaf Titz wrote:
> In article <[email protected]> you write:
> > [J Sloan]
> > >
> > > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
> >...
> > Those symbols are rather generic and rather important. Sounds like a
> > generic module problem. Do other modules load?
Yes, rtl8139, emu10k are loaded and working fine.
> Does your kernel use
> > MODVERSIONS?
Yes, I have CONFIG_MODVERSIONS=y
> (This module apparently doesn't.) Are you using a recent
> > version of modutils?
# insmod -V
insmod version 2.3.21
...
> The most important question: Did you run "make dep" after doing the patch?
Yes, after the patch, it was, as always:
make clean
make menuconfig
make dep bzlilo modules modules_install
Same problem with 2.4.0-test13-pre3-ac1 on
my Linux workstation at the office, where the
token ring driver fails as well (olympic.o)
BTW, in my experience to date with kernels from
2.3.36 up to 2.4.0-test-12 it has all worked well.
jjs
> List: linux-kernel
> Subject: Re: test13-pre3 woes
> From: Peter Samuelson <[email protected]>
> Date: 2000-12-18 9:19:13
> [Download message RAW]
>
>
> [J Sloan]
> > The module now compiles and gets installed -
> > Unfortunately, attempting to load it does not go well:
> >
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo
>
> Those symbols are rather generic and rather important. Sounds like a
> generic module problem. Do other modules load? Does your kernel use
> MODVERSIONS? (This module apparently doesn't.) Are you using a recent
> version of modutils?
>
> Puzzled. Maybe Keith Owens knows something.
>
> Peter
I got this, too. The one liner send here on lkm seems to be not enough. Even
Alan's ac1/2 did not do the trick. The 'new' Linux makefile changes brake
this stuff. It works before these changes.
So Rik any comments?
Thanks,
Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-K?lln-Stra?e 30
D-22527 Hamburg, Germany
email: [email protected]
@home: [email protected]
The saga continues into test13-pre3-ac3:
(last good tdfx.o was from test12)
# uname -a
Linux jyro.mirai.cx 2.4.0-test13pre3-ac3 #1 Tue Dec 19 21:26:36 PST 2000 i586
unknown
# lsmod
Module Size Used by
iptable_filter 1872 0 (autoclean) (unused)
ip_nat_ftp 3424 0 (unused)
iptable_nat 12672 1 [ip_nat_ftp]
ip_conntrack_ftp 2048 0 (unused)
ip_conntrack 13056 2 [ip_nat_ftp iptable_nat ip_conntrack_ftp]
ip_tables 10624 4 [iptable_filter iptable_nat]
ide-scsi 8096 0
8139too 15024 2 (autoclean)
emu10k1 45248 0
# modprobe tdfx
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol remap_page_range
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol __wake_up
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol mtrr_add
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol __generic_copy_from_user
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol schedule
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol kmalloc
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol si_meminfo
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol create_proc_entry
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol inter_module_put
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol __get_free_pages
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol boot_cpu_data
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol inter_module_get
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol remove_wait_queue
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol high_memory
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol iounmap
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol free_pages
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol __ioremap
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol del_timer
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol interruptible_sleep_on
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol __pollwait
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol kfree
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol remove_proc_entry
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol pci_find_slot
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol kill_fasync
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol fasync_helper
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol add_wait_queue
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol do_mmap_pgoff
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol mem_map
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol sprintf
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol jiffies
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol printk
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol add_timer
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved
sym
bol __generic_copy_to_user
/lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: insmod
/lib/mo
dules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o failed
Hope this helps -
jjs