On Tue, 17 Dec 2002 20:07:53 -0800 (PST) Linus Torvalds <torvalds@transmeta.com> wrote:
>
> Btw, on another tangent - Andrew Morton reports that APM is unhappy about
> the fact that the fast system call stuff required us to move the segments
> around a bit. That's probably because the APM code has the old APM segment
> numbers hardcoded somewhere, but I don't see where (I certainly knew about
> the segment number issue, and tried to update the cases I saw).
I looked at this yesterday and decided that it was OK as well.
> Debugging help would be appreciated, especially from somebody who knows
> the APM code.
It would help to know what "unhappy" means :-)
Does the following fix it for you? Untested, assumes cache lines are 32
bytes.
-- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/diff -ruN 2.5.52-200212181207/include/asm-i386/segment.h 2.5.52-200212181207-apm/include/asm-i386/segment.h --- 2.5.52-200212181207/include/asm-i386/segment.h 2002-12-18 15:25:48.000000000 +1100 +++ 2.5.52-200212181207-apm/include/asm-i386/segment.h 2002-12-18 15:38:34.000000000 +1100 @@ -65,9 +65,9 @@ #define GDT_ENTRY_APMBIOS_BASE (GDT_ENTRY_KERNEL_BASE + 11) /* - * The GDT has 23 entries but we pad it to cacheline boundary: + * The GDT has 25 entries but we pad it to cacheline boundary: */ -#define GDT_ENTRIES 24 +#define GDT_ENTRIES 28 #define GDT_SIZE (GDT_ENTRIES * 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/