login
Search
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ - The scheduler devel tree has been restored - The driver tree is presently busted, so I reverted it to the 2..23-rc8-mm1 version. - It's now a nearly-32MB diff. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail majordomo@vger.kernel.org - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Occasional snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.23-rc8-mm2: origin.patch git-acpi.patch git-alsa.patch git-arm.patch git-audit-master.patch git-avr32.patch git-cifs.patch git-cpufreq.patch git-powerpc.patch git-powerpc-galak.patch git-drm.patch git-dvb.patch git-hwmon.patch ...
Hi Andrew, The drivers/net/ibm_newemac/mal seems to be broken with 2.6.23-rc8-mm2 also, it was reported on 2.6.23-rc8-mm1 (http://lkml.org/lkml/2007/9/25/173). -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. -
On HP nx6325:
1) The audio is back (thanks for reverting x86_64-mm-cpa-einval.patch)
2) CPU hotplug is busted (onlining of CPU1 kills the kernel), probably due to
the same issue that I'm having with the -hrt version of 2.6.23-rc8 (we're
debugging it right now)
3) Some call traces unrelated to 2) appear in dmesg:
a) This probably is due to the fact that I've compiled two RTC drivers, by
mistake ;-)
Duplicate file names "rtc" detected.
Call Trace:
/home/rafael/src/mm/linux-2.6.23-rc8-mm2/drivers/usb/core/inode.c: creating file
'001'
usb usb3: new device found, idVendor=0000, idProduct=0000
usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: OHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.23-rc8-mm2 ohci_hcd
usb usb3: SerialNumber: 0000:00:13.1
[<ffffffff802d1b77>] proc_register+0x15b/0x173
[<ffffffff802d1c03>] create_proc_entry+0x74/0x89
[<ffffffff8811e05a>] :rtc_core:rtc_proc_add_device+0x25/0x48
[<ffffffff8811d229>] :rtc_core:rtc_device_register+0x182/0x215
[<ffffffff802d7f8b>] sysfs_add_one+0xbf/0xc9
[<ffffffff88160587>] :rtc_cmos:cmos_do_probe+0xa5/0x220
[<ffffffff88160743>] :rtc_cmos:cmos_pnp_probe+0x41/0x43
[<ffffffff80358805>] pnp_device_probe+0x7b/0xa2
[<ffffffff803825e4>] driver_probe_device+0x100/0x18f
[<ffffffff80382793>] __driver_attach+0x70/0xae
[<ffffffff80382723>] __driver_attach+0x0/0xae
[<ffffffff803818f8>] bus_for_each_dev+0x49/0x7a
[<ffffffff803823f6>] driver_attach+0x1c/0x1e
[<ffffffff80381cc5>] bus_add_driver+0x86/0x1d6
[<ffffffff803829a5>] driver_register+0x72/0x76
[<ffffffff803585a1>] pnp_register_driver+0x1c/0x1e
[<ffffffff880e3010>] :rtc_cmos:cmos_init+0x10/0x12
[<ffffffff80258398>] sys_init_module+0x16df/0x1864
[<ffffffff8811d0a7>] :rtc_core:rtc_device_register+0x0/0x215
[<ffffffff8020bfee>] system_call+0x7e/0x83
rtc_cmos 00:07: rtc core: registered rtc_cmos as rtc0
rtc_cmos: probe of 00:07 failed with error -16
b) I have no idea what causes these to ...This one is fixed by the following patch: --- From: Rafael J. Wysocki <rjw@sisk.pl> Fix CPU hotplug breakage on HP nx6325 and similar boxes caused by a reference to disable_apic_timer (labeled as __initdata) from the CPU initialization code. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> --- arch/x86_64/kernel/apic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.23-rc8-mm2/arch/x86_64/kernel/apic.c =================================================================== --- linux-2.6.23-rc8-mm2.orig/arch/x86_64/kernel/apic.c +++ linux-2.6.23-rc8-mm2/arch/x86_64/kernel/apic.c @@ -42,7 +42,7 @@ int apic_verbosity; static int apic_calibrate_pmtmr __initdata; -int disable_apic_timer __initdata; +int disable_apic_timer __cpuinitdata; /* Local APIC timer works in C2? */ int local_apic_timer_c2_ok; -
Doh, I knew I blew it. Good catch, thanks, -
Some good news from here. :-) WIth the patch below applied 2.6.23-rc8-mm2 works fine on the nx6325 _with_ NO_HZ and HIGH_RES_TIMERS set. Suspend and hibernation work as well, happy me. NO_HZ and HIGH_RES_TIMERS also work on this box with the hrt patch plus the C1E-related fix on top of 2.6.23-rc8. Does it make sense to test CPU_IDLE too at this point? Greetings, -- "Premature optimization is the root of all evil." - Donald Knuth -
This is with your configuration a reference from a .text section to a .init.data section as I see it. So this ought to have been flagged by the section mismatch checks in modpost. I assume you did not see such warning?? Sam -
I did: WARNING: vmlinux.o(.text+0x7778): Section mismatch: reference to .init.data:disable_apic_timer (between 'identify_cpu' and 'IRQ0x20_interrupt') --- ~Randy Phaedrus says that Quality is about caring. -
Thanks. I look forward to the day I can make them errors so people cannot ignore them. That said a lot of individuals has done a very good job getting rid of section mismatch warnings all over the kernel. Sam -
I did only on one build machine (multiple times). I tried to reproduce it on another machine and could not. I blame --- ~Randy Phaedrus says that Quality is about caring. -
That's possible. I use the default openSUSE 10.2 toolchain. Greetings, Rafael -
Le 27.09.2007 11:22, Andrew Morton a
On Thu, 27 Sep 2007 21:18:55 +0200 -
Got it. I'll try to reproduce. -- Dave -
This sure looks like a result of the reiserfs xattr code beeing really sucky and passing a NULL vfsmount to dentry_open. Dave will probably find a bandaid to work around this, but the right fix is to stop using a file struct here entirely. If you look at reiserfs_xattr_set it's not actually used at all except for passing it to ->prepare_write and ->commit_write which then don't use it at all. All that crap should be rewritten to just pass the dentry around. Note that all this should not acquire writer counts on the vfsmount - we have done this already before calling into the xattr methods. -
I'm perplexed as to why a 'struct file' is needed, too. The 'struct
file' doesn't get used for anything _but_ the dentry, and the functions
to which it is passed (reiserfs_prepate/commit_write()) don't use it.
In fact, some other callers just pass NULL.
This is a completely naive implementation, and I've only tested that it
compiles, but does anybody see a reason we can't just do this?
BTW, do reiserfs developers know that you can put function declarations
in header files? ;) 4 different .c files have this:
int reiserfs_commit_write(struct page *page, unsigned from, unsigned to);
int reiserfs_prepare_write(struct page *page, unsigned from, unsigned to);
---
lxc-dave/fs/reiserfs/inode.c | 15 ++++------
lxc-dave/fs/reiserfs/ioctl.c | 10 ++-----
lxc-dave/fs/reiserfs/xattr.c | 59 +++++++++++++------------------------------
3 files changed, 28 insertions(+), 56 deletions(-)
diff -puN fs/open.c~fix-reiserfs-oops fs/open.c
diff -puN fs/file_table.c~fix-reiserfs-oops fs/file_table.c
diff -puN include/linux/mount.h~fix-reiserfs-oops include/linux/mount.h
diff -puN fs/reiserfs/xattr.c~fix-reiserfs-oops fs/reiserfs/xattr.c
--- lxc/fs/reiserfs/xattr.c~fix-reiserfs-oops 2007-09-27 13:36:38.000000000 -0700
+++ lxc-dave/fs/reiserfs/xattr.c 2007-09-27 13:49:02.000000000 -0700
@@ -194,27 +194,6 @@ static struct dentry *get_xa_file_dentry
return xafile;
}
-/* Opens a file pointer to the attribute associated with inode */
-static struct file *open_xa_file(const struct inode *inode, const char *name,
- int flags)
-{
- struct dentry *xafile;
- struct file *fp;
-
- xafile = get_xa_file_dentry(inode, name, flags);
- if (IS_ERR(xafile))
- return ERR_PTR(PTR_ERR(xafile));
- else if (!xafile->d_inode) {
- dput(xafile);
- return ERR_PTR(-ENODATA);
- }
-
- fp = dentry_open(xafile, NULL, O_RDWR);
- /* dentry_open dputs the dentry if it fails */
-
- return fp;
-}
-
/*
* this is very similar to fs/reiserfs/dir.c:reiserfs_readdir, but
* we need to ...I doubt this will work. These are also used for the ->prepare_write and ->commit_write aops, and the method signature definitively wants a file there, even if it's zero.. -
Oddly enough, I don't see those functions being used in aops:
const struct address_space_operations reiserfs_address_space_operations = {
.writepage = reiserfs_writepage,
.readpage = reiserfs_readpage,
.readpages = reiserfs_readpages,
.releasepage = reiserfs_releasepage,
.invalidatepage = reiserfs_invalidatepage,
.sync_page = block_sync_page,
.write_begin = reiserfs_write_begin,
.write_end = reiserfs_write_end,
.bmap = reiserfs_aop_bmap,
.direct_IO = reiserfs_direct_IO,
.set_page_dirty = reiserfs_set_page_dirty,
};
Plus, reiserfs seems to compile with that patch I just sent. Sure as
heck surprised me.
-- Dave
-
On Thu, 27 Sep 2007 14:27:14 -0700 That'll be because reiserfs-convert-to-new-aops.patch witched reiserfs over to ->write_begin() and ->write_end(). So your stuff becomes dependent on Nick's stuff, and Nick's stuff is still failing on NFS, I think. -
On Thu, 27 Sep 2007 14:51:25 -0700 Actually, we should rename reiserfs_prepare_write and reiserfs_commit_write to something else to reduce confusion. Probably lots of other filesystems would benefit from the same change, post-Nick's-stuff. -
It worked today, it turned out to be a UML bug. Real hardware seemed to work properly, but will test a bit more tomorrow. -
I'd rather avoid the paramater removal for now, that makes it less entangle, and it's an unrelated cleanup anyway. Btw, there's more abuse of this sort in reiserfs. Various other places in xattr.c call dentry_open directly without the vfsmount aswell. And handling of an external journal uses filp_open which is similarly stupid, it should use open_bdev_excl like xfs or the generic code to open the main filesystem blockdevice. -
And here's a patch to stop the filp abuse in the journal code. An additional
benefit is that the block device is now properly claimed when opened by
device number.
Index: linux-2.6/fs/reiserfs/journal.c
===================================================================
--- linux-2.6.orig/fs/reiserfs/journal.c 2007-09-28 09:18:50.000000000 +0200
+++ linux-2.6/fs/reiserfs/journal.c 2007-09-28 09:28:36.000000000 +0200
@@ -2544,11 +2544,9 @@ static int release_journal_dev(struct su
result = 0;
- if (journal->j_dev_file != NULL) {
- result = filp_close(journal->j_dev_file, NULL);
- journal->j_dev_file = NULL;
- journal->j_dev_bd = NULL;
- } else if (journal->j_dev_bd != NULL) {
+ if (journal->j_dev_bd != NULL) {
+ if (journal->j_dev_bd->bd_dev != super->s_dev)
+ bd_release(journal->j_dev_bd);
result = blkdev_put(journal->j_dev_bd);
journal->j_dev_bd = NULL;
}
@@ -2573,7 +2571,6 @@ static int journal_init_dev(struct super
result = 0;
journal->j_dev_bd = NULL;
- journal->j_dev_file = NULL;
jdev = SB_ONDISK_JOURNAL_DEVICE(super) ?
new_decode_dev(SB_ONDISK_JOURNAL_DEVICE(super)) : super->s_dev;
@@ -2590,35 +2587,34 @@ static int journal_init_dev(struct super
"cannot init journal device '%s': %i",
__bdevname(jdev, b), result);
return result;
- } else if (jdev != super->s_dev)
+ } else if (jdev != super->s_dev) {
+ result = bd_claim(journal->j_dev_bd, journal);
+ if (result) {
+ blkdev_put(journal->j_dev_bd);
+ return result;
+ }
+
set_blocksize(journal->j_dev_bd, super->s_blocksize);
+ }
+
return 0;
}
- journal->j_dev_file = filp_open(jdev_name, 0, 0);
- if (!IS_ERR(journal->j_dev_file)) {
- struct inode *jdev_inode = journal->j_dev_file->f_mapping->host;
- if (!S_ISBLK(jdev_inode->i_mode)) {
- reiserfs_warning(super, "journal_init_dev: '%s' is "
- "not a block device", jdev_name);
- result = -ENOTBLK;
- release_journal_dev(super, journal);
- } else {
- /* ok ...Laurent, It triggered a WARNING on first run in qemu: [ 0.310000] WARNING: at arch/x86_64/kernel/smp.c:397 smp_call_function_mask() [ 0.310000] [ 0.310000] Call Trace: [ 0.310000] [<ffffffff8100dbde>] dump_trace+0x3ee/0x4a0 [ 0.310000] [<ffffffff8100dcd3>] show_trace+0x43/0x70 [ 0.310000] [<ffffffff8100dd15>] dump_stack+0x15/0x20 [ 0.310000] [<ffffffff8101cd44>] smp_call_function_mask+0x94/0xa0 [ 0.310000] [<ffffffff8101cd69>] smp_call_function+0x19/0x20 [ 0.310000] [<ffffffff8104277f>] on_each_cpu+0x1f/0x50 [ 0.310000] [<ffffffff81026eac>] global_flush_tlb+0x8c/0x110 [ 0.310000] [<ffffffff81025c85>] free_init_pages+0xe5/0xf0 [ 0.310000] [<ffffffff81549b5e>] alternative_instructions+0x7e/0x150 [ 0.310000] [<ffffffff8154a2ea>] check_bugs+0x1a/0x20 [ 0.310000] [<ffffffff81540c4a>] start_kernel+0x2da/0x380 [ 0.310000] [<ffffffff81540132>] _sinittext+0x132/0x140 Here is the more complete log: [ 0.000000] Linux version 2.6.23-rc8-mm2 (wfg@intel) (gcc version 4.2.1 (Debian 4.2.1-5)) #3 SMP Fri Sep 28 10:29:34 CST 2007 [ 0.000000] Command line: root=/dev/hda rw console=ttyS0 clock=pit init=/bin/bash [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 0000000039ff0000 (usable) [ 0.000000] BIOS-e820: 0000000039ff0000 - 000000003a000000 (ACPI data) [ 0.000000] BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved) [ 0.000000] end_pfn_map = 1048576 [ 0.000000] DMI not present or invalid. [ 0.000000] ACPI: RSDP 000FAA30, 0014 (r0 BOCHS ) [ 0.000000] ACPI: RSDT 39FF0000, 002C (r0 BOCHS BXPCRSDT 1 BXPC 1) [ 0.000000] ACPI: FACP 39FF002C, 0074 (r0 BOCHS BXPCFACP 1 BXPC 1) [ 0.000000] ACPI: DSDT 39FF0100, ...
the reason is the WARN_ON():
390 int smp_call_function_mask(cpumask_t mask,
391 void (*func)(void *), void *info,
392 int wait)
393 {
394 int ret;
395
396 /* Can deadlock when called with interrupts disabled */
397 WARN_ON(irqs_disabled());
398
399 spin_lock(&call_lock);
400 ret =3D __smp_call_function_mask(mask, func, info, wait);
401 spin_unlock(&call_lock);
402 return ret;
403 }
The patch I sent to Andi didn't include this WARN_ON() and it's why I did=
n't
find this issue. (see http://lkml.org/lkml/2007/8/24/101)
smp_call_function_mask() is called by smp_call_function() which calls a f=
unction
on all CPU except current.
The comment of smp_call_function() specifies:
=2E..
* You must not call this function with disabled interrupts or from a
* hardware interrupt handler or from a bottom half handler.
* Actually there are a few legal cases, like panic.
*/
So this WARN_ON() is correct, and the caller (global_flush_tlb()) doesn't=
follow
this rule.
I guess this WARN_ON() is only needed when we have current CPU in provide=
d mask.
So I think we should change:
int smp_call_function (void (*func) (void *info), void *info, int nonatom=
ic,
int wait)
{
return smp_call_function_mask(cpu_online_map, func, info, wait);
}
("cpu_online_map" is a bad choice, comment also specifies: "run a functio=
n on
all other CPU")
to
int smp_call_function (void (*func) (void *info), void *info, int nonatom=
ic,
int wait)
{
int ret;
cpumask_t allbutself;
allbutself =3D cpu_online_map;
cpu_clear(smp_processor_id(), allbutself);
spin_lock(&call_lock);
ret =3D __smp_call_function_mask(allbutself, func, info, wait);
spin_unlock(&call_lock);
return ret;
}
(which is smp_call_function_mask() without the WARN_ON() and without curr=
ent cpu
in the ...umm, I think all the smp_call_function fucntions are deadlocky if called with local interrupts disabled, regardless of whether the calling CPU is in the mask. If CPU A is sending a cross-cpu call to CPU B and CPU B is sending a cross-cpu call to CPU A, and they both have local interrupts disabled... -
=2E OK, so there are two errors: 1- one I introduce myself (without any help from anyone) where smp_call_function() calls all online CPUs instead of calling all CPUs exc= ept itself. 2- one in global_flush_tlb() which calls smp_call_function() with irqs di= sabled. I think I should at least correct #1 ? Laurent --=20 ------------- Laurent.Vivier@bull.net -------------- "Software is hard" - Donald Knuth
I'd be pretty surprised if one was able to write a bug like that. You mean the CPU sends an IPI to itself and then loops around until it has serviced that IPI? And this works? Wow. And on_each_cpu() can call the handler function twice? That would be a big bug, and surely we would already have picked it up. <looks> argh, mainline's x86_64 smp_call_function() doesn't do the check. We've had *heaps* of bugs in i386 where people were running smp_call_foo() under I think we should correct all bugs ;) -
This is a multi-part message in MIME format. --------------080006050504030805060306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In fact, it works because __smp_call_function_mask() makes : cpus_and(mask, mask, allbutself); So it removes current cpu from the mask. BTW, I don't have to modify smp_call_function(): it is correct as it is written (except from a semant= ic We don't live in a perfect world... ;-) Moreover, I'm not able to reproduce #2 ... Fengguang could you send me your .config and your qemu command line param= eters ? Laurent PS: if semantic is important, you can apply attached patch... --=20 ------------- Laurent.Vivier@bull.net -------------- "Software is hard" - Donald Knuth --------------080006050504030805060306 Content-Type: application/mbox; name="0001-smp_call_function-call-function-on-all-CPUs.patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; ...
OK. I applied your patch and reran it. Here are the qemu cmdline, warning messages and .config: qemu-system-x86_64 -m 928 -hda /dev/sdb5 -kernel ./arch/x86_64/boot/bzImage -nographic -append "root=/dev/hda rw console=ttyS0 clock=pit init=/bin/bash" [ 0.310000] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) [ 0.310000] CPU: L2 Cache: 512K (64 bytes/line) [ 0.310000] CPU 0/0 -> Node 0 [ 0.310000] SMP alternatives: switching to UP code [ 0.310000] Freeing SMP alternatives: 25k freed [ 0.310000] WARNING: at arch/x86_64/kernel/smp.c:397 smp_call_function_mask() [ 0.310000] [ 0.310000] Call Trace: [ 0.310000] [<ffffffff8100dbde>] dump_trace+0x3ee/0x4a0 [ 0.310000] [<ffffffff8100dcd3>] show_trace+0x43/0x70 [ 0.310000] [<ffffffff8100dd15>] dump_stack+0x15/0x20 [ 0.310000] [<ffffffff8101cd44>] smp_call_function_mask+0x94/0xa0 [ 0.310000] [<ffffffff8101d0b2>] smp_call_function+0x32/0x40 [ 0.310000] [<ffffffff8104277f>] on_each_cpu+0x1f/0x50 [ 0.310000] [<ffffffff81026eac>] global_flush_tlb+0x8c/0x110 [ 0.310000] [<ffffffff81025c85>] free_init_pages+0xe5/0xf0 [ 0.310000] [<ffffffff81549b5e>] alternative_instructions+0x7e/0x150 [ 0.310000] [<ffffffff8154a2ea>] check_bugs+0x1a/0x20 [ 0.310000] [<ffffffff81540c4a>] start_kernel+0x2da/0x380 [ 0.310000] [<ffffffff81540132>] _sinittext+0x132/0x140 [ 0.310000] [ 0.320000] ACPI: Core revision 20070126 [ 0.560000] Using local APIC timer interrupts. [ 0.590000] Detected 62.496 MHz APIC timer. [ 0.590000] Brought up 1 CPUs # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Fri Sep 28 10:26:40 ...
Thank god it's a bug in alternative_instructions() instead of global_flush_tlb(). The following patch fixed it. === call free_init_pages() with irqs enabled in alternative_instructions() It fixes the warning message in smp_call_function*(), which should be called with irqs disabled. [ 0.310000] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) [ 0.310000] CPU: L2 Cache: 512K (64 bytes/line) [ 0.310000] CPU 0/0 -> Node 0 [ 0.310000] SMP alternatives: switching to UP code [ 0.310000] Freeing SMP alternatives: 25k freed [ 0.310000] WARNING: at arch/x86_64/kernel/smp.c:397 smp_call_function_mask() [ 0.310000] [ 0.310000] Call Trace: [ 0.310000] [<ffffffff8100dbde>] dump_trace+0x3ee/0x4a0 [ 0.310000] [<ffffffff8100dcd3>] show_trace+0x43/0x70 [ 0.310000] [<ffffffff8100dd15>] dump_stack+0x15/0x20 [ 0.310000] [<ffffffff8101cd44>] smp_call_function_mask+0x94/0xa0 [ 0.310000] [<ffffffff8101d0b2>] smp_call_function+0x32/0x40 [ 0.310000] [<ffffffff8104277f>] on_each_cpu+0x1f/0x50 [ 0.310000] [<ffffffff81026eac>] global_flush_tlb+0x8c/0x110 [ 0.310000] [<ffffffff81025c85>] free_init_pages+0xe5/0xf0 [ 0.310000] [<ffffffff81549b5e>] alternative_instructions+0x7e/0x150 [ 0.310000] [<ffffffff8154a2ea>] check_bugs+0x1a/0x20 [ 0.310000] [<ffffffff81540c4a>] start_kernel+0x2da/0x380 [ 0.310000] [<ffffffff81540132>] _sinittext+0x132/0x140 [ 0.310000] [ 0.320000] ACPI: Core revision 20070126 [ 0.560000] Using local APIC timer interrupts. [ 0.590000] Detected 62.496 MHz APIC timer. [ 0.590000] Brought up 1 CPUs Cc: Laurent Vivier <Laurent.Vivier@bull.net> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn> --- arch/i386/kernel/alternative.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- linux-2.6.23-rc8-mm2.orig/arch/i386/kernel/alternative.c +++ linux-2.6.23-rc8-mm2/arch/i386/kernel/alternative.c @@ -435,9 +435,6 @@ void __init ...
Hello ! I just found that warning in my logs. It seems that it's been happening since rc7-mm1 at least. Thanks ! C. WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 tcp_fastretrans_alert() Call Trace: <IRQ> [<ffffffff8040fdc3>] tcp_ack+0xcd6/0x1894 [<ffffffff80411c79>] tcp_data_queue+0x5be/0xae7 [<ffffffff80412b54>] tcp_rcv_established+0x61f/0x6df [<ffffffff80254146>] __lock_acquire+0x8a1/0xf1b [<ffffffff80419cfd>] tcp_v4_do_rcv+0x3e/0x394 [<ffffffff8041a66f>] tcp_v4_rcv+0x61c/0x9a9 [<ffffffff803ff1e3>] ip_local_deliver+0x1da/0x2a4 [<ffffffff803ffb4e>] ip_rcv+0x583/0x5c9 [<ffffffff8046d33f>] packet_rcv_spkt+0x19a/0x1a8 [<ffffffff803e081c>] netif_receive_skb+0x2cf/0x2f5 [<ffffffff88042505>] :tg3:tg3_poll+0x65d/0x8a4 [<ffffffff803e09e8>] net_rx_action+0xb8/0x191 [<ffffffff8023a927>] __do_softirq+0x5f/0xe0 [<ffffffff8020c98c>] call_softirq+0x1c/0x28 [<ffffffff8020e9c3>] do_softirq+0x3b/0xb8 [<ffffffff8023aa1e>] irq_exit+0x4e/0x50 [<ffffffff8020e7df>] do_IRQ+0xbd/0xd7 [<ffffffff80209cb9>] mwait_idle+0x0/0x4d [<ffffffff8020bce6>] ret_from_intr+0x0/0xf <EOI> [<ffffffff80209cfc>] mwait_idle+0x43/0x4d [<ffffffff802099fb>] enter_idle+0x22/0x24 [<ffffffff80209c4f>] cpu_idle+0x9d/0xc0 [<ffffffff80476a91>] rest_init+0x55/0x57 [<ffffffff80630815>] start_kernel+0x2d6/0x2e2 [<ffffffff80630134>] _sinittext+0x134/0x13b -
...Thanks for the report, I'll have look what could still break fackets_out... -- i. -
I'm trying now to reproduce this WARNING. It seems that the n/w behaves differently during the week ends. Probably taking a break. C. -
On Sat, 29 Sep 2007, Cedric Le Goater wrote: > Ilpo J
got it ! r3-06.test.meiosys.com login: WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 tcp_fastretrans_alert() Call Trace: <IRQ> [<ffffffff8040fdc3>] tcp_ack+0xcd6/0x18af [<ffffffff80412b6f>] tcp_rcv_established+0x61f/0x6df [<ffffffff80254146>] __lock_acquire+0x8a1/0xf1b [<ffffffff80419d19>] tcp_v4_do_rcv+0x3e/0x394 [<ffffffff8041a68b>] tcp_v4_rcv+0x61c/0x9a9 [<ffffffff803ff1e3>] ip_local_deliver+0x1da/0x2a4 [<ffffffff803ffb4e>] ip_rcv+0x583/0x5c9 [<ffffffff8046d35b>] packet_rcv_spkt+0x19a/0x1a8 [<ffffffff803e081c>] netif_receive_skb+0x2cf/0x2f5 [<ffffffff88042505>] :tg3:tg3_poll+0x65d/0x8a4 [<ffffffff803e09e8>] net_rx_action+0xb8/0x191 [<ffffffff8023a927>] __do_softirq+0x5f/0xe0 [<ffffffff8020c98c>] call_softirq+0x1c/0x28 [<ffffffff8020e9c3>] do_softirq+0x3b/0xb8 [<ffffffff8023aa1e>] irq_exit+0x4e/0x50 [<ffffffff8020e7df>] do_IRQ+0xbd/0xd7 [<ffffffff80209cb9>] mwait_idle+0x0/0x4d [<ffffffff8020bce6>] ret_from_intr+0x0/0xf <EOI> [<ffffffff80209cfc>] mwait_idle+0x43/0x4d [<ffffffff802099fb>] enter_idle+0x22/0x24 [<ffffffff80209c4f>] cpu_idle+0x9d/0xc0 [<ffffffff80476aa1>] rest_init+0x55/0x57 [<ffffffff80630815>] start_kernel+0x2d6/0x2e2 [<ffffffff80630134>] _sinittext+0x134/0x13b TCP 0 I wasn't doing any particular test on n/w so it took me a while to figure out how I was triggering the WARNING. Apparently, this is happening when I run ketchup, but not always. This test machine is behind many firewall & routers so it might be a reason. tcpdump gave me this output for a wget on kernel.org : 10:51:14.835981 IP r3-06.test.meiosys.com.40322 > pub2.kernel.org.http: S 737836267:737836267(0) win 5840 <mss 1460,sackOK,timestamp 1309245 0,nop,wscale 7> 10:51:14.975153 IP pub2.kernel.org.http > r3-06.test.meiosys.com.40321: F 524:524(0) ack 166 win 5840 10:51:14.975177 IP r3-06.test.meiosys.com.40321 > pub2.kernel.org.http: . ack 525 win 7504 I'm trying to get the WARNING and the tcpdump output for it but for ...
I'm currently out of ideas where it could come from... so lets try
brute-force checking as your test case is not very high-speed... This
could hide it though... :-(
Please put the patch below on top of clean rc8-mm2 (it includes the patch
I gave you last time) and try to reproduce.... These counter bugs can
survive for sometime until !sacked_out condition occurs, so the patch
below tries to find that out when inconsisteny occurs for the first time
regardless of sacked_out (I also removed some statics which hopefully
reduces compiler inlining for easier reading of the output). I tried this
myself (except for verify()s in frto funcs and minor printout
modifications), didn't trigger for me.
--
i.
---
include/net/tcp.h | 3 +
net/ipv4/tcp_input.c | 23 +++++++++--
net/ipv4/tcp_ipv4.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++++
net/ipv4/tcp_output.c | 6 ++-
4 files changed, 128 insertions(+), 6 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 991ccdc..54a0d91 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -43,6 +43,9 @@
#include <linux/seq_file.h>
+extern void tcp_verify_fackets(struct sock *sk);
+extern void tcp_print_queue(struct sock *sk);
+
extern struct inet_hashinfo tcp_hashinfo;
extern atomic_t tcp_orphan_count;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e22ffe7..1d7367d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1140,7 +1140,7 @@ static int tcp_check_dsack(struct tcp_sock *tp, struct sk_buff *ack_skb,
return dup_sack;
}
-static int
+int
tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_una)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
@@ -1160,6 +1160,8 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
int first_sack_index;
if (!tp->sacked_out) {
+ if (WARN_ON(tp->fackets_out))
+ tcp_print_queue(sk);
tp->fackets_out = 0;
...# find /proc >/dev/null find: WARNING: Hard link count is wrong for /proc/net: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched. # stat net File: `net' Size: 0 Blocks: 0 IO Block: 1024 directory Device: 3h/3d Inode: 4026531864 Links: 2 Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2007-09-28 18:21:24.651209759 +0200 Modify: 2007-09-28 18:21:24.651209759 +0200 Change: 2007-09-28 18:21:24.651209759 +0200 # stat net/ File: `net/' Size: 0 Blocks: 0 IO Block: 1024 directory Device: 3h/3d Inode: 4026531909 Links: 4 Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2007-09-28 18:26:48.813048220 +0200 Modify: 2007-09-28 18:26:48.813048220 +0200 Change: 2007-09-28 18:26:48.813048220 +0200 hmm, this is some kind of weirdness :) regards, -- Jiri Slaby (jirislaby@gmail.com) Faculty of Informatics, Masaryk University -- Jiri Slaby (jirislaby@gmail.com) Faculty of Informatics, Masaryk University -
Yes. I can explain it. For the network namespace stuff we need special handling of /proc/net so that depending on the network namespace we are resolving against you see a different behavior. So you actually are observing two different directories, one being a magic invisible symlink to the other. Currently I am resolving against current (which has a number of limitations) and the weird ugly effect you are current seeing. So it looks like I need to either make /proc/net a symlink to /proc/self/net or make the network namespace something that we capture at mount time of /proc. This was my don't get hung up on this implementation detail version. Thanks for pointing out it has user visible problems. I will see what I can do to resolve this. Eric -
Hi, The kernel report warnings about sysfs filename duplicate under rc8-mm1 and rc8-mm2. 1. ----cut---- NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfb93e, last bus=3 PCI: Using configuration type 1 Setting up standard PCI resources sysfs: duplicate filename 'usbcore' can not be created WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() [<c010528f>] dump_trace+0x1bf/0x1d0 [<c0105358>] show_trace_log_lvl+0x18/0x30 [<c010537f>] show_trace+0xf/0x20 [<c01054a2>] dump_stack+0x12/0x20 [<c01c6680>] sysfs_add_one+0xa0/0xe0 [<c01c69e8>] create_dir+0x48/0xb0 [<c01c6a99>] sysfs_create_dir+0x29/0x50 [<c02501eb>] create_dir+0x1b/0x50 [<c02504b6>] kobject_add+0x46/0x150 [<c05a38a0>] kernel_param_sysfs_setup+0x50/0xb0 [<c05a39ee>] param_sysfs_builtin+0xee/0x130 [<c05a3a54>] param_sysfs_init+0x24/0x60 [<c0592866>] do_initcalls+0x46/0x1e0 [<c0592aa2>] kernel_init+0x62/0xb0 [<c0104fb3>] kernel_thread_helper+0x7/0x14 ======================= kobject_add failed for usbcore with -EEXIST, don't try to register things with the same name in the same directory. [<c010528f>] dump_trace+0x1bf/0x1d0 [<c0105358>] show_trace_log_lvl+0x18/0x30 [<c010537f>] show_trace+0xf/0x20 [<c01054a2>] dump_stack+0x12/0x20 [<c0250566>] kobject_add+0xf6/0x150 [<c05a38a0>] kernel_param_sysfs_setup+0x50/0xb0 [<c05a39ee>] param_sysfs_builtin+0xee/0x130 [<c05a3a54>] param_sysfs_init+0x24/0x60 [<c0592866>] do_initcalls+0x46/0x1e0 [<c0592aa2>] kernel_init+0x62/0xb0 [<c0104fb3>] kernel_thread_helper+0x7/0x14 ======================= Module 'usbcore' failed to be added to sysfs, error number -17 The system will be unstable now. ACPI: EC: Look up EC in DSDT 2. ----cut---- ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 21 (level, low) -> IRQ 18 PCI: Setting latency timer of device 0000:00:1d.7 to 64 ehci_hcd 0000:00:1d.7: EHCI Host Controller ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1 ehci_hcd ...
That is very wierd, do you have both USB built in and as a module I think I need to clean up the double stack trace here, that's reall not needed :) thanks, greg k-h -
I dont think so, below is my .config file: (It works under rc8 tree) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Sat Sep 29 16:55:51 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not ...
From: Greg KH <greg@kroah.com> I get some identical warnings from iftab in userspace: eth1 renamed to switch sysfs: duplicate filename 'switch' can not be created WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() Call Trace: [<ffffffff802cb99c>] sysfs_add_one+0xac/0xe0 [<ffffffff802cc8fc>] sysfs_create_link+0xac/0x140 [<ffffffff803fa632>] device_rename+0x1c2/0x220 [<ffffffff80500ccc>] dev_change_name+0xbc/0x250 [<ffffffff80501198>] dev_ifsioc+0x338/0x3a0 [<ffffffff8050156d>] dev_ioctl+0x36d/0x3c0 [<ffffffff80271965>] handle_mm_fault+0x1a5/0x6f0 [<ffffffff804f215d>] sock_ioctl+0x7d/0x250 [<ffffffff80293cb1>] do_ioctl+0x31/0x90 [<ffffffff80293f2b>] vfs_ioctl+0x21b/0x2d0 [<ffffffff8029402a>] sys_ioctl+0x4a/0x80 [<ffffffff8020bc8e>] system_call+0x7e/0x83 net switch: device_rename: sysfs_create_symlink failed (-17) eth2 renamed to adsl sysfs: duplicate filename 'adsl' can not be created WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() Call Trace: [<ffffffff802cb99c>] sysfs_add_one+0xac/0xe0 [<ffffffff802cc8fc>] sysfs_create_link+0xac/0x140 [<ffffffff803fa632>] device_rename+0x1c2/0x220 [<ffffffff80500ccc>] dev_change_name+0xbc/0x250 [<ffffffff80501198>] dev_ifsioc+0x338/0x3a0 [<ffffffff8050156d>] dev_ioctl+0x36d/0x3c0 [<ffffffff80271965>] handle_mm_fault+0x1a5/0x6f0 [<ffffffff804f215d>] sock_ioctl+0x7d/0x250 [<ffffffff80293cb1>] do_ioctl+0x31/0x90 [<ffffffff80293f2b>] vfs_ioctl+0x21b/0x2d0 [<ffffffff8029402a>] sys_ioctl+0x4a/0x80 [<ffffffff8020bc8e>] system_call+0x7e/0x83 net adsl: device_rename: sysfs_create_symlink failed (-17) switch: no link during initialization. ip_tables: (C) 2000-2006 Netfilter Core Team this happens when iftab renames my network interfaces. Booting 2.6.21-rc1-mm2 said: eth1 renamed to switch eth2 renamed to adsl ip_tables: (C) 2000-2006 Netfilter Core Team 2.6.23-rc4-mm1 said: eth1 renamed to switch net switch: device_rename: sysfs_create_symlink failed (-17) eth2 renamed to adsl net adsl: device_rename: ...
Hi, I debugged the problem, found that it is a bug of kernel/params.c, I will send a patch later to fix it. Regards dave -
Locks up hard at very early boot on my Dell Latitude - grub says loading kernel, the screen clears, and we lock up before we get penguins. -rc8-mm1 was OK. I'm off to go bisect, figured I'd drop a heads-up.
It doesn't ring a bell, sorry. hpet-force-enable-on-ich34.patch is known to be bad, but it causes failure later in the boot than that. -
Yep, that was it - I applied that one patch on top of -rc8-mm2 and it came up without complaint. That was certainly one that would make the CPU head off into the weeds very early in boot. I need to figure how how I managed to botch the git bisect - it flagged the very last commit, when the problem was commit N-1.
OK, now I'm confoozled. I built -rc8-mm2, and it bricked. Usually my first test is then using quilt to push just origin.patch, so I know if I'm needing to bisect Linus git or Andrew -mm. Starting with a clean 23-rc8, and using 'quilt push origin.patch' to just add the Linus changes *also* gets me a brick. So I did a git bisect between 23-rc8 and the first commit listed in origin.patch, and got down to this: f7f847b01571e86044dc77e03d92f43699652f8d is first bad commit commit f7f847b01571e86044dc77e03d92f43699652f8d Author: Linus Torvalds <torvalds@woody.linux-foundation.org> Date: Wed Sep 26 15:21:33 2007 -0700 (Here's the 'git bisect log': git-bisect start # good: [4942de4a0e914f205d351a81873f4f63986bcc3c] Linux 2.6.23-rc8 git-bisect good 4942de4a0e914f205d351a81873f4f63986bcc3c # bad: [f7f847b01571e86044dc77e03d92f43699652f8d] Revert "x86-64: Disable local APIC timer use on AMD systems with C1E" git-bisect bad f7f847b01571e86044dc77e03d92f43699652f8d # good: [4d3fac08718b49fc256bdb447a479d089ca97b78] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev git-bisect good 4d3fac08718b49fc256bdb447a479d089ca97b78 # good: [d85f57938ad1d674dff8077a2e6a36a45dbe0e22] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git-bisect good d85f57938ad1d674dff8077a2e6a36a45dbe0e22 # good: [d8c4a2f9d9e7827362fd7ab0b5d9637c6af5ac5b] mv643xx_eth: duplicate methods in initializer git-bisect good d8c4a2f9d9e7827362fd7ab0b5d9637c6af5ac5b # good: [255129d1e9ca0ed3d69d5517fae3e03d7ab4b806] NLM: Fix a circular lock dependency in lockd git-bisect good 255129d1e9ca0ed3d69d5517fae3e03d7ab4b806 # good: [e66485d747505e9d960b864fc6c37f8b2afafaf0] x86-64: Disable local APIC timer use on AMD systems with C1E git-bisect good e66485d747505e9d960b864fc6c37f8b2afafaf0 # good: [df912ea4ae7233d1504fbd861ee127bd7ee5781d] xen: execve's error paths don't pin the mm before unpinning git-bisect good ...
Hi Andrew, The compilation with the cross compiler for the PowerPC-405 on the powerbox fails at linking LD init/built-in.o LD .tmp_vmlinux1 ld: arch/powerpc/kernel/head_64.o(.text+0x80c8): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern ld: arch/powerpc/kernel/head_64.o(.text+0x8160): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern ld: arch/powerpc/kernel/head_64.o(.text+0x81c4): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern ld: final link failed: Bad value make: *** [.tmp_vmlinux1] Error 1 -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. -
Adding CC to the powerpc mailing list -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. -
Here's a nearly-useless bug report for ya: The -mm kernels between rc4-mm1 and rc8-mm1 have been locking up for me in X when run for about a day or so. The crash does not appear correlated with any particular action on my part - it seems just as likely to happen if I'm typing in a local editor or over an ssh session or using my web browser. The capslock light blinks, so it's probably generating a trace and it still responds to sysrq but no logs make it to disk. As my laptop generally doesn't stay put for a whole day, I haven't managed to capture any of these traces. System is a Thinkpad R51, here's the config. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Mon Oct 8 21:58:21 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not ...
