Swap doesn't work

Hi Alan

Not that I would know better or have an idea why this bug happens, but to say "Bugger off if you have an lfs system" is a bit lousy, I think. After all, lfs has not really an "unstrusted toolchain", as compared to RH/Suse's/Debian "trustworthy computing toolchains":

lfs has a manual with clearly specified package versions, patches and order of "toolchaining". It might well be a bug in that chain, but other distros have bugs, too. Signing software doesn't make it superior, after all.

However, the error does not happen on my crappy lfs system, but then again, I run it in a vmware, with the virtual disks set up as scsi...

Bye
Tim

Sorry, tons of people that have absolute no clue about the package internals set up their systems themselves and make mistakes. nothing spectacular, but they just don't have those people who know the packages in detail and can notice and fix the bugs. Just get binary rpm/deb whatever of the toolchain and reproduce.

but having people who understand the software maintain the packages sometimes helps :)

As I said, I can't reproduce it even on my lfs system, maybe because my disks are scsi. So reproducing on my Red Hat wouldn't really help, would it?

As far as I know, lfs does not maintain the packages. binutils and gcc are maintained by FSF to my knowledge.

Bye
Tim

I get bugs that are clearly caused by miscompiled tool chains from Linux from scratch people. I trust the RH, SuSE and Debian tool chains because they have any neccessary patches applied for compiler bugs and they are running against a properly built glibc and binutils.

If you simply grab the latest and greatest of everything from ftp.gnu.org then quite often it won't work.

If you'd like to me to spend hours debugging an LFS system where its probably a tool error, then you can ask for current hourly rates.

Alan

That's certainly true and before claiming a kernel bug, I would try against a Red Hat System personally. Still, lfs does have gcc patches included, it's not just cvs checkout from the relevant packages. It also seems to have a sane order of compiling everything.

That wasn't actually my idea. And you are right, before claiming a kernel bug one should probably always try to reproduce it against a different system.

Bye
Tim

Hi all,

Lately I've been struggeling with kernels Oopsing in page_alloc.c, rmqueue() function. The line which triggers the Oops is actually in expand() which is inlined from rmqueue() (and others). In my kernel source (2.4.20-pre11), expand looks like this :

#define MARK_USED(index, order, area) \
        __change_bit((index) >> (1+(order)), (area)->map)

static inline struct page * expand (zone_t *zone, struct page *page,
unsigned long index, int low, int high, free_area_t * area)

{
        unsigned long size = 1 << high;

        while (high > low) {
                if (BAD_RANGE(zone,page))
                        BUG();
                area--;
                high--;
                size >>= 1;
                list_add(&(page)->list, &(area)->free_list);
                MARK_USED(index, high, area);
                index += size;
                page += size;
        }
        if (BAD_RANGE(zone,page))
                BUG();
        return page;
}

The line that triggers the BUG is the last BAD_RANGE check. The module that calls __alloc_pages() is doing it in the following way :

addr = __get_free_page(GFP_KERNEL);

and frees the page with free_page(addr);

The machine configuration is RedHat 7.3 (gcc-2.96-110, binutils-2.11.93.0.2-11), 2 Xeon processors @ 2.2 GHz and 2GB RAM.

The module in question is not a part of the kernel tree, but the source is available if someone is interested. However, I'm really interrested in situations that could cause BAD_RANGE() to fail (since it is commented with a "Temporary debugging check") because of the above usage (which seems very straight forward to me).

The really strange thing is that the problem seem to disappear if I apply the per_cpu_pages patch by Ingo Molnar as found in the RedHat 2.4.18-17.7.x kernel with a few modifications to make it fit on 2.4.20-pre11 (attached).

Any help greatly appreciated.

Thanks,
--

  Steffen Persvold   |       Scali AS      
 mailto:[email protected] |  http://www.scali.com
Tel: (+47) 2262 8950 |   Olaf Helsets vei 6
Fax: (+47) 2262 8951 |   N0621 Oslo, NORWAY

@@ -26,6 +26,14 @@
 
 struct pglist_data;
 
+#define MAX_PER_CPU_PAGES 512
+
+typedef struct per_cpu_pages_s {
+	int nr_pages;
+	int max_nr_pages;
+	struct list_head head;
+} __attribute__((aligned(L1_CACHE_BYTES))) per_cpu_t;
+
 /*
  * On machines where it is needed (eg PCs) we divide physical memory
  * into multiple physical zones. On a PC we have 3 zones:

@@ -38,6 +46,7 @@
 	/*
 	 * Commonly accessed fields:
 	 */
+	per_cpu_t		cpu_pages [NR_CPUS];
 	spinlock_t		lock;
 	unsigned long		free_pages;
 	unsigned long		pages_min, pages_low, pages_high;