Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
Hello Mike, hello Linus, Some minutes ago, I wrote: > I think I have found the reason for our bugs. It seems GCC really > miscompiles buffer.c:bdflush_init without frame pointers. I'll try harder > now to understand what excactly is going on, but it seems it is smashing > its local stack space by decrementing its stack pointer too early, then > calling an assembler function (__down_failed). It might be that GCC is > confused by this. [...] > Any comments on this? I'll now try to split up the stack space operation in > two parts, the first after call kernel_thread: addl $12, %esp (as in the > first call), and an additional addl $64, %esp just before leaving (before > popl %ebx). And I'll report what happened, later - but I have a good > feeling that I have caught the bug. ... and my good feeling was right. Changing the bogus assembly code made the bug go away. I'll try to prepare a simpler testcase for the GCC maintainers tomorrow. For short, this is what happens: GCC tries to free its stack frame for the local variables far too early. It then calls __down_failed(), which pushes some things on the stack - thereby corrupting the semaphore pointer! So __down() works on a random memory location instead of the semaphore, which is guaranteed to fail badly. I've added linux-kernel as CC again, so everybody can now hear that this is definitely a GCC bug, and not a kernel issue. Greetings, Andreas -- ->>>--- Andreas Franck <<<- ---<<< [EMAIL PROTECTED] --->>>--- ->>> Keep smiling! <<<- - 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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Mon, Dec 25, 2000 at 08:40:50PM + or thereabouts, Thorsten Kranzkowski wrote:
> On Mon, Dec 25, 2000 at 06:09:35AM +0100, Mike Galbraith wrote:
> > I wouldn't (not going to here;) spend a lot of time on it. The compiler
> > has problems. It won't build glibc-2.2, and chokes horribly on ipchains.
> >
> > int ipt_register_table(struct ipt_table *table)
> > {
> > int ret;
> > struct ipt_table_info *newinfo;
> > static struct ipt_table_info bootstrap
> > = { 0, 0, { 0 }, { 0 }, { } };
> >^
> > ip_tables.c:1361: Internal compiler error in array_size_for_constructor, at
>varasm.c:4456
>
>
> Well, I 'fixed' this by changing above line to:
> = { 0, 0, { 0 }, { 0 }, };
> and repeating this change (deleting the braces) about 15 times in 2 or 3 other
> files of iptables. (patch available on request)
> Of course gcc shouldn't die but issue a useful message if/when syntax rules
> may have changed.
>
> Apart from that and a hand-edited arch/alpha/vmlinux.lds that got some
> newlines wrong, the kernel compiled fine and is up for over a day now.
> Though this is not intel but alpha (ev4 / AXPpci33).
>
> Marvin:~$ uname -a
> Linux Marvin 2.4.0-test13pre4-ac2 #13 Sun Dec 24 15:26:57 UTC 2000 alpha unknown
> Marvin:~$ uptime
> 8:19pm up 1 day, 4:28, 4 users, load average: 0.00, 0.00, 0.00
> Marvin:~$ gcc -v
> Reading specs from /usr/lib/gcc-lib/alpha-unknown-linux-gnu/2.97/specs
> Configured with: ../gcc-20001211/configure --enable-threads --enable-shared
>--prefix=/usr --enable-languages=c,c++
> gcc version 2.97 20001211 (experimental)
>
>
> I use iptables for masquerading my local ethernet and that works as expected
> so far.
>
> Thorsten.
Its a problem with initializing a zero-length array. This is something
that gcc has never previously been documented to do, but it has worked
in the past (most of the time). Recently it has been decided (according
to traffic on gcc-bugs and gcc-patches lists) that gcc will handle
zero-length arrays as flexable-array-members per ISO C99 standard.
AFAIK, that means that if they are to be initialized, zero-length arrays
can only exist as the last element of a structure, and that the
structure must not be embeded within another structure.
The empty brackets that Thorsten removed were initializing the zero-length
array to empty, but gcc currently has this bit of code in varasm.c
(around line 4460):
/* ??? I'm fairly certain if there were no elements, we shouldn't have
created the constructor in the first place. */
if (max_index == NULL_TREE)
abort ();
This abort() resulted in the "Internal compiler error" that Mike noticed
earlier. Removing the empty brackets prevents gcc from trying to
initialize the zero length array and avoids this problem. However, this
can result in warning messages about missing initializers depending upon
the warning flags given to gcc, and seems like the wrong thing to do.
The best solution (IMHO) for this situation is to change gcc/varasm.c to
accept empty initializers, something like:
/* ??? I'm fairly certain if there were no elements, we shouldn't have
created the constructor in the first place. */
/* No, it can be useful to initialize the zero-length array with an
empty initializer. */
if (max_index == NULL_TREE)
return 0;
The rest of netfilter will still not compile because in several other C
files the initialized zero-length arrays are nested several structures
deep. If we can convince the gcc folks to drop some of the ISO C99
restrictions on the use of zero-length arrays then all will be back to
normal (as Ulrich Drepper pointed out, the ISO committee in their
infinite wisdom does not always come up with a standard that is the best
solution in the real world). But I am not sure if that is the best
solution. Perhaps it would be better to change the netfilter code. In
any event, the gcc documentation does not say anything about not being
able to initialize zero-length arrays to empty, so this is a bug and I'm
going to talk with the gcc folks.
-Paul Laufer
-
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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Mon, Dec 25, 2000 at 06:09:35AM +0100, Mike Galbraith wrote:
> I wouldn't (not going to here;) spend a lot of time on it. The compiler
> has problems. It won't build glibc-2.2, and chokes horribly on ipchains.
>
> int ipt_register_table(struct ipt_table *table)
> {
> int ret;
> struct ipt_table_info *newinfo;
> static struct ipt_table_info bootstrap
> = { 0, 0, { 0 }, { 0 }, { } };
>^
> ip_tables.c:1361: Internal compiler error in array_size_for_constructor, at
>varasm.c:4456
Well, I 'fixed' this by changing above line to:
= { 0, 0, { 0 }, { 0 }, };
and repeating this change (deleting the braces) about 15 times in 2 or 3 other
files of iptables. (patch available on request)
Of course gcc shouldn't die but issue a useful message if/when syntax rules
may have changed.
Apart from that and a hand-edited arch/alpha/vmlinux.lds that got some
newlines wrong, the kernel compiled fine and is up for over a day now.
Though this is not intel but alpha (ev4 / AXPpci33).
Marvin:~$ uname -a
Linux Marvin 2.4.0-test13pre4-ac2 #13 Sun Dec 24 15:26:57 UTC 2000 alpha unknown
Marvin:~$ uptime
8:19pm up 1 day, 4:28, 4 users, load average: 0.00, 0.00, 0.00
Marvin:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/alpha-unknown-linux-gnu/2.97/specs
Configured with: ../gcc-20001211/configure --enable-threads --enable-shared
--prefix=/usr --enable-languages=c,c++
gcc version 2.97 20001211 (experimental)
I use iptables for masquerading my local ethernet and that works as expected
so far.
Thorsten.
--
| Thorsten KranzkowskiInternet: [EMAIL PROTECTED]|
| Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] |
-
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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Mon, 25 Dec 2000, Andreas Franck wrote: > Hello Mike, hello linux-kernel hackers, > > Mike Galbraith wrote: > > I wouldn't (not going to here;) spend a lot of time on it. The compiler > > has problems. It won't build glibc-2.2, and chokes horribly on ipchains. > > Maybe, but you were lucky getting an ICE, and not silently failing code :-) You bet. > After having spent several hours debugging now, I think it was > worth it (at least for my understanding of lower-level kernel issues and of > the (rather nice and almost readable) assembly code gcc generates). There Don't get me wrong, chasing things like this is never a waste of time. In the case of gcc in particular. Our next 'stable' kernel compiler is going to come from the gcc development tree just as the next 'stable' kernel is coming out of the kernel development tree. -Mike - 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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Mon, 25 Dec 2000, Andreas Franck wrote: > Hello Mike, hello linux-kernel hackers, > > Mike Galbraith wrote: > > I wouldn't (not going to here;) spend a lot of time on it. The compiler > > has problems. It won't build glibc-2.2, and chokes horribly on ipchains. > > Maybe, but after having spent several hours debugging now, I think it was > worth it: I am almost sure this is not a gcc bug, but a nasty race condition > involving the semaphore handling bdflush_init. > > I figured out by spilling some printk's around in bdflush_init, which made > the bug magically disappear, what wasn't what I intended - but which gave me > a clearer impression of what's going on. Oh? Can you show me (offline) what you did exactly that made it go away? (that's kinda scary.. _much_ prefer 'compiler has rough edges' option;) -Mike - 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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
Hello Mike, hello linux-kernel hackers, Mike Galbraith wrote: > I wouldn't (not going to here;) spend a lot of time on it. The compiler > has problems. It won't build glibc-2.2, and chokes horribly on ipchains. Maybe, but after having spent several hours debugging now, I think it was worth it: I am almost sure this is not a gcc bug, but a nasty race condition involving the semaphore handling bdflush_init. I figured out by spilling some printk's around in bdflush_init, which made the bug magically disappear, what wasn't what I intended - but which gave me a clearer impression of what's going on. It seems that whyever, the cause for this failure is actually the down(sem) call on a not yet up()'ed semaphore, and this is where it starts to get ugly. -- ->>>--- Andreas Franck <<<- ---<<< [EMAIL PROTECTED] --->>>--- ->>> Keep smiling! <<<- - 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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
Hello Mike, hello linux-kernel hackers, Mike Galbraith wrote: > I wouldn't (not going to here;) spend a lot of time on it. The compiler > has problems. It won't build glibc-2.2, and chokes horribly on ipchains. Maybe, but you were lucky getting an ICE, and not silently failing code :-) After having spent several hours debugging now, I think it was worth it (at least for my understanding of lower-level kernel issues and of the (rather nice and almost readable) assembly code gcc generates). There seems to be something going wrong in the down(sem) path after the kernel_thread call. I'm not sure if down() succeeds instantly when compiling the kernel with 2.95.2, but it seems to fail for 2.97; I figured out by spilling some printk's around in bdflush_init, which made the bug magically disappear, due to the looser timing. This also might happen for compiling with frame pointers or with the static declaration variables, somehow. Th bdflush_init function itself does not seem to be responsible, which corresponds with the assembly, which is fine and should get the same results for all compiled cases. It seems that whyever, the cause for this failure is actually the down(sem) call on a not yet up()'ed semaphore, and this is where it starts to get ugly. down() then calls __down_failed, which ends up in __down(); __down does some waitqueue handling, which I don't understand, and then calls __wake_up - up to then, everything seems fine, in __wake_up it is where my search ended up to now, but I think something is wrong in this context; however, the complexity of this code exceeds my knowledge by magnitudes, so I can't continue searching there without going mad :-) It would be nice if someone else could look from there on, now I've narrowed the case down to rather low-level functions. Greetings, Andreas -- ->>>--- Andreas Franck <<<- ---<<< [EMAIL PROTECTED] --->>>--- ->>> Keep smiling! <<<- - 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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Sun, 24 Dec 2000, Andreas Franck wrote:
> Hello Mike, hello linux-kernel hackers,
>
> Mike Galbraith wrote:
>
> > Yes, hmm indeed. Try these two things.
> >
> > 1. make DECLARE_MUTEX_LOCKED(sem) in bdflush_init() static.
> > 2. compile with frame pointers. (normal case for IKD)
> >
> > My IKD tree works with either option, but not with neither. I haven't
> > figured out why yet.
>
> 1 worked for me, too - with the same effect as compiling buffer.c with
> 2.95.2, thus meaning successful boot and heavy crashing later on.
> I haven't tried to boot 2 yet, but this looks seriously fishy to me. It would
> be nice if we could make a simpler testcase to reproduce it, as it's much
> work to boot the kernel over and over again.
I wouldn't (not going to here;) spend a lot of time on it. The compiler
has problems. It won't build glibc-2.2, and chokes horribly on ipchains.
int ipt_register_table(struct ipt_table *table)
{
int ret;
struct ipt_table_info *newinfo;
static struct ipt_table_info bootstrap
= { 0, 0, { 0 }, { 0 }, { } };
^
ip_tables.c:1361: Internal compiler error in array_size_for_constructor, at
varasm.c:4456
-Mike
-
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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
Hello Mike, hello linux-kernel hackers, Mike Galbraith wrote: > Yes, hmm indeed. Try these two things. > > 1. make DECLARE_MUTEX_LOCKED(sem) in bdflush_init() static. > 2. compile with frame pointers. (normal case for IKD) > > My IKD tree works with either option, but not with neither. I haven't > figured out why yet. 1 worked for me, too - with the same effect as compiling buffer.c with 2.95.2, thus meaning successful boot and heavy crashing later on. I haven't tried to boot 2 yet, but this looks seriously fishy to me. It would be nice if we could make a simpler testcase to reproduce it, as it's much work to boot the kernel over and over again. I have now printed out the buffer.c:bdflush_init assembly for all four cases, 2.95.2, 2.97 without patch, 2.97 with static DECLARE... and 2.97 with frame pointer, and will try to figure out what's going wrong - it would still be nice to know if its a gcc problem or if some kernel assumption about GCC behaviour triggered this bug, which seems equally likely, as kernel_thread and the mutex/semaphore stuff involve some nontrivial (at least for beginners like me...) hand-made assembly code. A nice evening and still merry christmas to the people westward of Europe :-) Andreas -- ->>>--- Andreas Franck <<<- ---<<< [EMAIL PROTECTED] --->>>--- ->>> Keep smiling! <<<- - 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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Sat, 23 Dec 2000, Andreas Franck wrote: > Hi Mike, hello linux-kernel audience, > > > I had the same, with the last few snapshots I tried, but 20001218 seems > > to work ok. > > dmesg|head -1 > > Linux version 2.4.0-test13ikd (root@el-kaboom) (gcc version gcc-2.97 > > 20001218 (experimental)) #18 Sat Dec 23 17:43:29 CET 2000 > > Hmm, would have been nice, but it crashes here with 20001222, nevertheless. > For which CPU do you have your kernel configured? It might be a CPU specific > issue, I'll try to compile for Pentium I and 486, now, and report my results. Yes, hmm indeed. Try these two things. 1. make DECLARE_MUTEX_LOCKED(sem) in bdflush_init() static. 2. compile with frame pointers. (normal case for IKD) My IKD tree works with either option, but not with neither. I haven't figured out why yet. -Mike - 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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
The story continues, citing myself: > Hmm, would have been nice, but it crashes here with 20001222, nevertheless. > For which CPU do you have your kernel configured? It might be a CPU > specific issue, I'll try to compile for Pentium I and 486, now, and report > my results. It does not seem CPU specific, breaks for both 486 and Pentium with the same error. > It would also be nice to know if this is a gcc issue or a kernel issue - if > I knew which precise file was responsible for the crash, I could compare > the assembly output for stable and snapshot GCC. My suspect is > kernel/sched.c, but this might be wrong, as the story begins on the launch > of kupdate in fs/buffer.c. And this is where everything seems to go wrong: When I compile buffer.c with 2.95.2, and link everything together, the kernel magically boots without any complaints; later on something starts crashing badly, but this might be other issues that can be investigated later on. > But now I have almost no clue what really goes wrong ... and now I have a bit more, and the suspection that something broke the way in which the kernel_thread function (arch/i386/kernel/process.c) wants to start the kernel threads, here bdflush and kupdate. I don't understand all issues completely, but something seems to have changed. Attached are the relevant (?) portions of the assembly output for buffer.c: kupdate, bdflush and bdflush_init, compiled with 2.95.2 and 2.97, respectively. Perhaps someone could look over it? Thanks and happy hacking, Andreas -- ->>>--- Andreas Franck <<<- ---<<< [EMAIL PROTECTED] --->>>--- ->>> Keep smiling! <<<- buffer-2.95.2.S buffer-2.97.S
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
Hi Mike, hello linux-kernel audience, > I had the same, with the last few snapshots I tried, but 20001218 seems > to work ok. > dmesg|head -1 > Linux version 2.4.0-test13ikd (root@el-kaboom) (gcc version gcc-2.97 > 20001218 (experimental)) #18 Sat Dec 23 17:43:29 CET 2000 Hmm, would have been nice, but it crashes here with 20001222, nevertheless. For which CPU do you have your kernel configured? It might be a CPU specific issue, I'll try to compile for Pentium I and 486, now, and report my results. It would also be nice to know if this is a gcc issue or a kernel issue - if I knew which precise file was responsible for the crash, I could compare the assembly output for stable and snapshot GCC. My suspect is kernel/sched.c, but this might be wrong, as the story begins on the launch of kupdate in fs/buffer.c. But now I have almost no clue what really goes wrong. Geetings and a nice christmas to everybody! Andreas -- ->>>--- Andreas Franck <<<- ---<<< [EMAIL PROTECTED] --->>>--- ->>> Keep smiling! <<<- - 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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Sat, 23 Dec 2000, Andreas Franck wrote: > Hello, > > I hope I am not doing something particularly stupid here, but as Linus > encouraged curious people to try compiling the kernel with the > latest gcc snapshots, I have tried - as several weeks before, but again > in vain. > > Since I have tried, the same following error on early boot (just after > "Starting kswapd v1.8" appears on the screen) has bitten me, when I > compiled the kernel with a recent gcc snapshot. This was for at least > 2.4.0-test11 with gcc snapshots from 2 months ago till yesterday. Hi, I had the same, with the last few snapshots I tried, but 20001218 seems to work ok. dmesg|head -1 Linux version 2.4.0-test13ikd (root@el-kaboom) (gcc version gcc-2.97 20001218 (experimental)) #18 Sat Dec 23 17:43:29 CET 2000 -Mike - 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/
Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
Hello, I hope I am not doing something particularly stupid here, but as Linus encouraged curious people to try compiling the kernel with the latest gcc snapshots, I have tried - as several weeks before, but again in vain. Since I have tried, the same following error on early boot (just after "Starting kswapd v1.8" appears on the screen) has bitten me, when I compiled the kernel with a recent gcc snapshot. This was for at least 2.4.0-test11 with gcc snapshots from 2 months ago till yesterday. The ksymoops output is attached here, and I hope it will help. I tried to narrow it down by myself a bit, and ended in kernel/sched.c: __wake_up_common, where my understanding of the code came to a sudden end, so I hope some gurus here will be able to figure out what's wrong. All (?) relevant output should be found below, if anything important is missing, I am willing to provide aly further information later on. I don't know if this happens if I compile the kernel for something less than Pentium II, this is what I have tried (System is a PII-266 with 160MB RAM on an Intel 430LX motherboard). With gcc version 2.95.2 2220 (Debian GNU/Linux) everything works perfectly fine. Thanks for any advice and happy hacking! Andreas Here comes all important info: ---snip--- ksymoops 2.3.5 on i686 2.4.0-test12. Options used -V (default) -K (specified) -l /proc/modules (default) -o /lib/modules/2.4.0-test13-pre4/ (specified) -m /usr/src/linux/System.map (specified) No modules in ksyms, skipping objects No ksyms, skipping lsmod Unable to handle kernel paging request at virtual address fe4c c0114e9d *pde = 1063 Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010097 eax: c40effb8 ebx: c3585a59 ecx: fe4c edx: esi: c0107b0c edi: fff9 ebp: c12b9fc8 esp: c12b9fa4 ds: 0018 es: 0018 ss: 0018 Process kupdate (pid 6, stackpage=c12b900) Stack: 0246 c40effb8 0001 0003 c12b8000 fff9 c12b8000 c0107b38 c40effac c12b8550 c01f896f 00010f00 c40eff74 00105000 0008e000 c0107486 c40effac c0137900 Call Trace: [] [] [] [] [] [] Code: 8b 01 85 45 f0 74 ec 8b 7d dc 85 ff 74 79 8b 45 ec 8b 16 21 >>EIP; c0114e9d <__wake_up+5d/140> <= Trace; fff9 Trace; c0107b38 <__up_wakeup+8/c> Trace; c01f896f Trace; c0105000 Trace; c0107486 Trace; c0137900 Code; c0114e9d <__wake_up+5d/140> <_EIP>: Code; c0114e9d <__wake_up+5d/140> <= 0: 8b 01 mov(%ecx),%eax <= Code; c0114e9f <__wake_up+5f/140> 2: 85 45 f0 test %eax,0xfff0(%ebp) Code; c0114ea2 <__wake_up+62/140> 5: 74 ec je fff3 <_EIP+0xfff3> c0114e90 <__wake_up+50/140> Code; c0114ea4 <__wake_up+64/140> 7: 8b 7d dc mov0xffdc(%ebp),%edi Code; c0114ea7 <__wake_up+67/140> a: 85 ff test %edi,%edi Code; c0114ea9 <__wake_up+69/140> c: 74 79 je 87 <_EIP+0x87> c0114f24 <__wake_up+e4/140> Code; c0114eab <__wake_up+6b/140> e: 8b 45 ec mov0xffec(%ebp),%eax Code; c0114eae <__wake_up+6e/140> 11: 8b 16 mov(%esi),%edx Code; c0114eb0 <__wake_up+70/140> 13: 21 00 and%eax,(%eax) gcc snapshot version: Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.97/specs Configured with: ../gcc/configure --prefix=/usr --enable-shared --enable-threads gcc version 2.97 20001222 (experimental) My .config: # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_M686FXSR is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y
