headers
Randy.Dunlap | 3 Nov 2003 05:12

[PATCH/RFC] Re: Crash-on-boot in init_l440gx SMP

Would someone comment on this patch from lkml last Friday?

Thanks,
~Randy

Date: 	Fri, 31 Oct 2003 11:48:49 -0800
From: "Randy.Dunlap" <rddunlap <at> osdl.org>
To: bruce <at> perens.com (Bruce Perens)
Cc: linux-kernel <at> vger.kernel.org, dwmw2 <at> infradead.org
Subject: [PATCH/RFC] Re: Crash-on-boot in init_l440gx SMP
Message-Id: <20031031114849.3e2c5425.rddunlap <at> osdl.org>
In-Reply-To: <20031030200203.159BD321 <at> workstation.perens.com>
References: <20031030200203.159BD321 <at> workstation.perens.com>
Organization: OSDL

On Thu, 30 Oct 2003 12:02:03 -0800 (PST) bruce <at> perens.com (Bruce Perens) wrote:

| Hi,
| 
| Using -test9, I'm hitting BUG_ON(phys_addr + size < phys_addr) in ioremap.c,
| called from init_l440gx with a dual Pentum 3 SMP motherboard. Boot log with
| oops, and ksymoops output are attached. This system is main server for
| perens.com, and thus hasn't exercised 2.6 much. Please email me if I can be
| of any further assistance.
| 
| ------------[ cut here ]------------
| kernel BUG at arch/i386/mm/ioremap.c:202!
| invalid operand: 0000 [#1]
| CPU:    0
| EIP:    0060:[<c011e778>]    Not tainted
(Continue reading)

Permalink | Reply | 0 comments |
headers
IWAMOTO Toshihiro | 4 Nov 2003 11:29
Picon
Favicon

memory hotremove prototype, take 2

Hi,

As you may know, I'm working on memory hotplug.
(See http://marc.theaimsgroup.com/?l=linux-kernel&m=106637967926960
for my original patch.)
I fixed several fatal bugs in the original patch and it works much
better.  The updated version is included in this mail.
I confirmed successful "make -j4" cross-build of NetBSD libc while
rotating active and inactive zones and remapping pages of inactive
zones.

However, I discovered my page remapping approach has a fatal flaw and
ext2_rename caused a deadlock.  Let me explain the situation.

To put it simple, what my patch does is:
    for each page (called "oldpage" hereafter) do
        1. allocate "newpage" as a replacement
        2. increment oldpage's page count
        3. rewrite oldpage radix entry with the one of newpage,
         so that find_get_page and its friends return newpage
        4. wait until page_count(oldpage) drops to 1
        5. copy oldpage's content to newpage,
         SetPageUptodate(newpage), unlock_page(newpage)
        6. oldpage can be freed

ext2_rename does:

        old_de = ext2_find_entry (old_dir, old_dentry, &old_page);
              :
              :
(Continue reading)

Permalink | Reply | 0 comments |
headers
request | 4 Nov 2003 14:54

Regarding: mail.nl.linux.org/linux-mm/2000-05/msg00418.html/index.html#00418

Hello,

This e-mail has been sent to inform you that your 
web site URL has been submitted to our search engine
database. This is the URL that will be added.

    URL : mail.nl.linux.org/linux-mm/2000-05/msg00418.html/index.html#00418
   DATE : 11/4/2003 8:54:59
IP ADDR : Unknown IP. User had used an automated software for url submission

In order to complete this request we require that you 
click on the web site link below. This will confirm
that you do wish to be added to our search engine.

http://www.global-submit.com/confirm.cgi?T137180R139336

If you feel that you received this message in error
or you did not have your web site submitted to our
search engine, please click on the link below. We 
will make every effort to make sure that you are 
no longer bothered by this automated system. 

http://www.global-submit.com/clipout.cgi?T137180R139336

Thank you and please have a nice day

Global-Submit.com tech Staff
www.global-submit.com
1 819 571 4943
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 5 Nov 2003 07:55

2.6.0-test9-mm2

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm2/

- Various random fixes.  Maybe about half of these are 2.6.0-worthy.

- Some improvements to the anticipatory IO scheduler and more readahead
  tweaks should help some of those database benchmarks.

  The anticipatory scheduler is still a bit behind the deadline scheduler
  in these random seeky loads - it most likely always will be.

- "A new driver for the ethernet interface of the NVIDIA nForce chipset,
  licensed under GPL."

  Testing of this would be appreciated.  Send any reports to linux-kernel
  or netdev <at> oss.sgi.com and Manfred will scoop them up, thanks.

- I shall be offline for a couple of days.

Changes since 2.6.0-test9-mm1:

 linus.patch

 Latest Linus tree

-might_sleep-suppression.patch

 Dropped - Linus fixed the vm86 might_sleep() warning for real.

+as-badness-warning-fix.patch
+as-request-poisoning.patch
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Hoogerhuis | 5 Nov 2003 13:30

Re: 2.6.0-test9-mm2

Andrew Morton <akpm <at> osdl.org> writes:
>
> [SNIP]
>

FWIW, it compiles nicely, runs nicely and as with -mm1, I haven't
really found problems I can't blame myself for (seems to go bonk from
time to time with vmware modules, likewise with the orinoco-usb
driver, but without those it is very nice :)

mvh,
A
--

-- 
Alexander Hoogerhuis                               | alexh <at> ihatent.com
CCNP - CCDP - MCNE - CCSE                          | +47 908 21 485
"You have zero privacy anyway. Get over it."  --Scott McNealy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
John Cherry | 5 Nov 2003 17:10

Re: 2.6.0-test9-mm2 (compile stats)

Linux 2.6 (mm tree) Compile Statistics (gcc 3.2.2)
Warnings/Errors Summary

Kernel             bzImage   bzImage  bzImage  modules  bzImage  modules
                 (defconfig) (allno)  (allyes) (allyes) (allmod)(allmod)
---------------  ---------- -------- -------- -------- -------- --------
2.6.0-test9-mm2    0w/0e     0w/0e   172w/ 0e  12w/0e   3w/0e    211w/1e
2.6.0-test9-mm1    0w/0e     0w/0e   179w/ 1e  12w/0e   3w/0e    213w/1e
2.6.0-test8-mm1    0w/0e     0w/0e   183w/ 1e  13w/0e   3w/0e    223w/1e
2.6.0-test7-mm1    0w/0e     1w/0e   176w/ 1e   9w/0e   3w/0e    231w/1e
2.6.0-test6-mm4    0w/0e     1w/0e   179w/ 1e   9w/0e   3w/0e    234w/1e
2.6.0-test6-mm3    0w/0e     1w/0e   178w/ 1e   9w/0e   3w/0e    252w/2e
2.6.0-test6-mm2    0w/0e     1w/0e   179w/ 1e   9w/0e   3w/0e    252w/2e
2.6.0-test6-mm1    0w/0e     1w/0e   179w/ 1e   9w/0e   3w/0e    252w/2e

Web page with links to complete details:
   http://developer.osdl.org/cherry/compile/

Version information for host [ cherrypit.pdx.osdl.net ]
 gcc:    3.2.2
 patch:  2.5.4

Kernel version: 2.6.0-test9-mm2
Kernel build: 
   Making bzImage (defconfig): 0 warnings, 0 errors
   Making modules (defconfig): 0 warnings, 0 errors
   Making bzImage (allnoconfig): 0 warnings, 0 errors
   Making bzImage (allyesconfig): 172 warnings, 0 errors
   Making modules (allyesconfig): 12 warnings, 0 errors
   Making bzImage (allmodconfig): 3 warnings, 0 errors
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alistair John Strachan | 5 Nov 2003 18:02
Picon
Picon

Re: 2.6.0-test9-mm2

On Wednesday 05 November 2003 06:55, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2
>.6.0-test9-mm2/
>
>
> - Various random fixes.  Maybe about half of these are 2.6.0-worthy.
>
> - Some improvements to the anticipatory IO scheduler and more readahead
>   tweaks should help some of those database benchmarks.
>
>   The anticipatory scheduler is still a bit behind the deadline scheduler
>   in these random seeky loads - it most likely always will be.
>
> - "A new driver for the ethernet interface of the NVIDIA nForce chipset,
>   licensed under GPL."
>
>   Testing of this would be appreciated.  Send any reports to linux-kernel
>   or netdev <at> oss.sgi.com and Manfred will scoop them up, thanks.
>

I tried the force driver on my nForce2 machine and although it mostly works 
(DHCP works, I can receive mail over the interface, etc..) it doesn't seem to 
handle really bulky loads. For example, I'm running an FTP server on the 
machine (proftpd), and although FTP navigation works just fine, transferring 
large files just causes the transfer to hang indefinitely.

Removing the driver and using NVIDIA's proprietary driver allows me to 
transfer via FTP properly.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin J. Bligh | 6 Nov 2003 00:07

Re: 2.6.0-test9-mm2

Seems to work fine on my box. Nothing very interesting from a performance
perspective, but it does seem a touch faster than mainline on kernbench.
NFI why ;-)

Kernbench: (make -j N vmlinux, where N = 2 x num_cpus)
                              Elapsed      System        User         CPU
              2.6.0-test9       45.28      100.19      568.01     1474.75
          2.6.0-test9-mm2       44.83      100.79      567.74     1491.00
         2.6.0-test9-mjb1       43.73       80.19      559.91     1463.25

Kernbench: (make -j N vmlinux, where N = 16 x num_cpus)
                              Elapsed      System        User         CPU
              2.6.0-test9       46.17      122.20      571.58     1501.00
          2.6.0-test9-mm2       45.89      120.39      570.67     1504.75
         2.6.0-test9-mjb1       43.52       89.98      562.91     1500.50

Kernbench: (make -j vmlinux, maximal tasks)
                              Elapsed      System        User         CPU
              2.6.0-test9       45.84      120.14      570.93     1507.00
          2.6.0-test9-mm2       44.21      118.81      571.28     1566.00
         2.6.0-test9-mjb1       43.73       87.19      564.39     1488.50

DISCLAIMER: SPEC(tm) and the benchmark name SDET(tm) are registered
trademarks of the Standard Performance Evaluation Corporation. This 
benchmarking was performed for research purposes only, and the run results
are non-compliant and not-comparable with any published results.

Results are shown as percentages of the first set displayed

SDET 1  (see disclaimer)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Mokryn | 6 Nov 2003 17:09

Highmem SCSI driver

We are trying to test 64-bit PCI DMA for a SCSI driver on a Xeon box,

RH9 2.4.20-8 bigmem kernel, 6GB RAM.
The machine shows 6GB in top, we set highmem_io in the driver, PCI DMA 
mask covers 64-bit range, etc.

Of course we're trying to make sure that the system does not create 
bounce buffers unnecessarily. On a 64-bit box (AMD64) everything works 
as expected. On the Xeon, no matter what we try, we never see I/Os 
mapped above 4GB.

Any ideas on how we can drive I/Os mapped above 4GB down to our driver?

Thanks,
-Mark

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
Sharath Kodi Udupa | 8 Nov 2003 01:35
Picon

linux vm page sharing

hi,

i am trying to implement a system where different processes can share
pages, this means that not only same executables, but different
executables , but when the pages required are same.
but i see in the linux page structure, it keeps a pointer to the
address_space mapping, but now since if the second process also needs to
share the page,this wont be the same mapping. so i am planning to add the
page table entry to the second process, but to leave the
struct address_space *mapping pointer to whatever it was earlier. I plan
to do this since, i dont really understand how this is used and also have
gone through the code to understand it. What significance does this hold?

any pointers is greatly appreciated

regards,

Sharath K Udupa
Graduate Student,
Dept. of Computer Science,
University of Arizona.
sku <at> cs.arizona.edu
http://www.cs.arizona.edu/~sku

"Sometimes I think the surest sign that intelligent life exists
elsewhere in the universe is that none of it has tried to contact us."
--Calvin, The Indispensable Calvin and Hobbes

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
(Continue reading)

Permalink | Reply | 1 comment |

Gmane