Re: 2.6.23-rc8-mm2 ACPI Battery Info in /sys but not /proc/acpi
On Fri, 2007-10-19 at 11:59 -0400, Chris Bandy wrote: > I had this same problem, but found that it was because I turned off the > newly deprecated CONFIG_ACPI_PROCFS. This was the problem. Thank you. What confused me was that *only* the battery information seemed to be missing. If all the ACPI info in /proc had been missing I would have suspected something like this right away. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.23-rc8-mm2
On Thu, Sep 27, 2007 at 02:22:20AM -0700, Andrew Morton wrote: > > 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. 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 set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=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_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_PARAVIRT=y # CONFIG_XEN is not set # CONFIG_VMI is not set # 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 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MPENTIUM4 is not set # CONFIG_MCORE2 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG
Re: 2.6.23-rc8-mm2
On 9/29/07, Greg KH <[EMAIL PROTECTED]> wrote: > On Sat, Sep 29, 2007 at 05:37:29PM +0800, Dave Young wrote: > > 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() > > [] dump_trace+0x1bf/0x1d0 > > [] show_trace_log_lvl+0x18/0x30 > > [] show_trace+0xf/0x20 > > [] dump_stack+0x12/0x20 > > [] sysfs_add_one+0xa0/0xe0 > > [] create_dir+0x48/0xb0 > > [] sysfs_create_dir+0x29/0x50 > > [] create_dir+0x1b/0x50 > > [] kobject_add+0x46/0x150 > > [] kernel_param_sysfs_setup+0x50/0xb0 > > [] param_sysfs_builtin+0xee/0x130 > > [] param_sysfs_init+0x24/0x60 > > [] do_initcalls+0x46/0x1e0 > > [] kernel_init+0x62/0xb0 > > [] 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. > > That is very wierd, do you have both USB built in and as a module > somehow? > > > [] dump_trace+0x1bf/0x1d0 > > [] show_trace_log_lvl+0x18/0x30 > > [] show_trace+0xf/0x20 > > [] dump_stack+0x12/0x20 > > [] kobject_add+0xf6/0x150 > > [] kernel_param_sysfs_setup+0x50/0xb0 > > [] param_sysfs_builtin+0xee/0x130 > > [] param_sysfs_init+0x24/0x60 > > [] do_initcalls+0x46/0x1e0 > > [] kernel_init+0x62/0xb0 > > [] kernel_thread_helper+0x7/0x14 > > === > > Module 'usbcore' failed to be added to sysfs, error number -17 > > I think I need to clean up the double stack trace here, that's reall not > needed :) > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Don Mullis wrote: > That patch boots without complaint as well. > > BTW, the earlier failure messages did not make it > into /var/log/messages, only the dmesg buffer. > This is with standard Ubuntu Gutsy logging levels. Super, thanks for retesting! -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
That patch boots without complaint as well.
BTW, the earlier failure messages did not make it
into /var/log/messages, only the dmesg buffer.
This is with standard Ubuntu Gutsy logging levels.
On Thu, 2007-10-04 at 18:42 +0200, Jens Axboe wrote:
> On Thu, Oct 04 2007, Pierre Ossman wrote:
> > On Thu, 04 Oct 2007 09:19:40 -0700
> > Don Mullis <[EMAIL PROTECTED]> wrote:
> >
> > > This patch fixes the boot.
> > >
> >
> > Fantastic. Then will try to get this upstream then.
>
> I already put it in the sgchain drivers part. If you could please ack
> it, that would be nice :-). I have a bunch of driver
> updates/work-arounds there.
>
> > > > It looks like missing init of the sg list in mmc, does this work?
> > > >
> >
> > Jens, is this zeroing needed for each invocation, or really just once
> > to get the list in a known state?
>
> Once should actually be enough, so you could move it to init as well.
> Don, care to verify with the below patch as well?
>
> > Also, is chaining already upstream so Linus should have this for 2.6.23?
>
> No, it's for 2.6.24.
>
> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
> index b0abc7d..a5d0354 100644
> --- a/drivers/mmc/card/queue.c
> +++ b/drivers/mmc/card/queue.c
> @@ -153,14 +153,14 @@ int mmc_init_queue(struct mmc_queue *mq, struct
> mmc_card *card, spinlock_t *lock
> blk_queue_max_hw_segments(mq->queue, bouncesz / 512);
> blk_queue_max_segment_size(mq->queue, bouncesz);
>
> - mq->sg = kmalloc(sizeof(struct scatterlist),
> + mq->sg = kzalloc(sizeof(struct scatterlist),
> GFP_KERNEL);
> if (!mq->sg) {
> ret = -ENOMEM;
> goto cleanup_queue;
> }
>
> - mq->bounce_sg = kmalloc(sizeof(struct scatterlist) *
> + mq->bounce_sg = kzalloc(sizeof(struct scatterlist) *
> bouncesz / 512, GFP_KERNEL);
> if (!mq->bounce_sg) {
> ret = -ENOMEM;
> @@ -177,7 +177,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
> *card, spinlock_t *lock
> blk_queue_max_hw_segments(mq->queue, host->max_hw_segs);
> blk_queue_max_segment_size(mq->queue, host->max_seg_size);
>
> - mq->sg = kmalloc(sizeof(struct scatterlist) *
> + mq->sg = kzalloc(sizeof(struct scatterlist) *
> host->max_phys_segs, GFP_KERNEL);
> if (!mq->sg) {
> ret = -ENOMEM;
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 18:42:25 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > > diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c > index b0abc7d..a5d0354 100644 > --- a/drivers/mmc/card/queue.c > +++ b/drivers/mmc/card/queue.c Acked-by: Pierre Ossman <[EMAIL PROTECTED]> (Provided it works ;)) I have no patches touching queue.c in my tree, so there should be no problems with merge conflicts. Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote:
> On Thu, 04 Oct 2007 09:19:40 -0700
> Don Mullis <[EMAIL PROTECTED]> wrote:
>
> > This patch fixes the boot.
> >
>
> Fantastic. Then will try to get this upstream then.
I already put it in the sgchain drivers part. If you could please ack
it, that would be nice :-). I have a bunch of driver
updates/work-arounds there.
> > > It looks like missing init of the sg list in mmc, does this work?
> > >
>
> Jens, is this zeroing needed for each invocation, or really just once
> to get the list in a known state?
Once should actually be enough, so you could move it to init as well.
Don, care to verify with the below patch as well?
> Also, is chaining already upstream so Linus should have this for 2.6.23?
No, it's for 2.6.24.
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index b0abc7d..a5d0354 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -153,14 +153,14 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
*card, spinlock_t *lock
blk_queue_max_hw_segments(mq->queue, bouncesz / 512);
blk_queue_max_segment_size(mq->queue, bouncesz);
- mq->sg = kmalloc(sizeof(struct scatterlist),
+ mq->sg = kzalloc(sizeof(struct scatterlist),
GFP_KERNEL);
if (!mq->sg) {
ret = -ENOMEM;
goto cleanup_queue;
}
- mq->bounce_sg = kmalloc(sizeof(struct scatterlist) *
+ mq->bounce_sg = kzalloc(sizeof(struct scatterlist) *
bouncesz / 512, GFP_KERNEL);
if (!mq->bounce_sg) {
ret = -ENOMEM;
@@ -177,7 +177,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
*card, spinlock_t *lock
blk_queue_max_hw_segments(mq->queue, host->max_hw_segs);
blk_queue_max_segment_size(mq->queue, host->max_seg_size);
- mq->sg = kmalloc(sizeof(struct scatterlist) *
+ mq->sg = kzalloc(sizeof(struct scatterlist) *
host->max_phys_segs, GFP_KERNEL);
if (!mq->sg) {
ret = -ENOMEM;
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 04 Oct 2007 09:19:40 -0700 Don Mullis <[EMAIL PROTECTED]> wrote: > This patch fixes the boot. > Fantastic. Then will try to get this upstream then. > > > > It looks like missing init of the sg list in mmc, does this work? > > Jens, is this zeroing needed for each invocation, or really just once to get the list in a known state? Also, is chaining already upstream so Linus should have this for 2.6.23? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
This patch fixes the boot.
On Thu, 2007-10-04 at 09:25 +0200, Jens Axboe wrote:
> On Wed, Oct 03 2007, Andrew Morton wrote:
> > On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis <[EMAIL PROTECTED]> wrote:
> >
> > > OOPS followed by a 3 minute timeout, then completion of boot.
> > > Not seen if card (Kingston microSD adapter) is ejected; not seen in
> > > 2.6.23-rc8.
> > > Running on a Dell XPS M1330 laptop.
> > >
> > > `dmesg` reports:
> > >
> > > [ 13.695045] mmcblk0: mmc0:e95c SD02G 1966080KiB
> > > [ 13.695155] mmcblk0: p1
> > > [ 13.706907] BUG: unable to handle kernel paging request at virtual
> > > address 6b6b6b7a
> > > [ 13.707026] printing eip: c01f09f0 *pde =
> > > [ 13.707174] Oops: [#1] SMP
> > > [ 13.707326] last sysfs file: /class/mmc_host/mmc0/mmc0:e95c/serial
> > > [ 13.707389] Modules linked in: mmc_block sr_mod iwl4965 cdrom
> > > serio_raw mac80211 piix sdhci pcspkr psmouse ide_core iTCO_wdt
> > > iTCO_vendor_support watchdog_core watchdog_dev cfg80211 mmc_core shpchp
> > > pci_hotplug intel_agp agpgart battery ac power_supply button evdev
> > > ata_generic ext3 jbd mbcache sg sd_mod usbhid hid ahci ata_piix libata
> > > scsi_mod ohci1394 tg3 ieee1394 ehci_hcd uhci_hcd thermal processor fan
> > > fuse
> > > [ 13.709649]
> > > [ 13.709705] Pid: 4089, comm: mmcqd Not tainted (2.6.23-rc8-mm2 #27)
> > > [ 13.709767] EIP: 0060:[] EFLAGS: 00010206 CPU: 0
> > > [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160
> > > [ 13.709889] EAX: 04b6a000 EBX: c4a030e0 ECX: 04b6b000 EDX: c100
> > > [ 13.709951] ESI: 6b6b6b6a EDI: c11535d0 EBP: c4971e30 ESP: c4971df4
> > > [ 13.710013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
> > > [ 13.710074] Process mmcqd (pid: 4089, ti=c497 task=c387b660
> > > task.ti=c497)
> > > [ 13.710137] last branch before last exception/interrupt
> > > [ 13.710249] from c0129bf8 (vprintk+0x1d8/0x340)
> > > [ 13.710359] to c0129c9c (vprintk+0x27c/0x340)
> > > [ 13.710453] Stack: c4971e08 c013d85f c48a0440 2000 04b6c000
> > > c3914180 0001 0001
> > > [ 13.710920]1000 c4923700 0100 c48ca3a0
> > > c48f6d88 c48f6d88 c4971e40
> > > [ 13.711390]f8c39e58 c48f6d88 c4a9f020 c4971fbc f8c396c9
> > > c017de04 0004 c4971e84
> > > [ 13.711857] Call Trace:
> > > [ 13.711971] [] mmc_queue_map_sg+0x28/0xc0 [mmc_block]
> > > [ 13.712085] [] mmc_blk_issue_rq+0x199/0x780 [mmc_block]
> > > [ 13.712193] [] mmc_queue_thread+0x78/0xe0 [mmc_block]
> > > [ 13.712309] [] kthread+0x42/0x70
> > > [ 13.712415] [] kernel_thread_helper+0x7/0x14
> > > [ 13.712523] ===
> > > [ 13.712584] Code: 0c 03 4f 08 8b 7f 04 01 cf 89 7d d4 8b 3b 89 f8 29
> > > d0 c1 f8 03 69 c0 39 8e e3 38 c1 e0 0c 03 43 08 39 45 d4 74 73 90 8d 74
> > > 26 00 <8b> 46 10 8d 4e 10 89 3e 89 c2 83 e2 fe a8 01 8b 45 e4 0f 45 ca
> > > [ 13.71] EIP: [] blk_rq_map_sg+0xc0/0x160 SS:ESP
> > > 0068:c4971df4
> > > [ 13.845668] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1c0b1, caps:
> > > 0xa04753/0x20
> > > [ 13.879914] input: SynPS/2 Synaptics TouchPad as /class/input/input7
> > > [ 192.162711] Adding 2731008k swap on /dev/sda7. Priority:-1 extents:1
> > > across:2731008k
> >
> > This could be due to git-block changes (or a lack of them ;))
>
> It looks like missing init of the sg list in mmc, does this work?
>
> --- linux-2.6.23-rc8/drivers/mmc/card/queue.c~2007-10-04
> 09:22:02.0 +0200
> +++ linux-2.6.23-rc8/drivers/mmc/card/queue.c 2007-10-04 09:23:13.0
> +0200
> @@ -334,14 +334,18 @@ static void copy_sg(struct scatterlist *
>
> unsigned int mmc_queue_map_sg(struct mmc_queue *mq)
> {
> + struct request *rq = mq->req;
> unsigned int sg_len;
>
> - if (!mq->bounce_buf)
> - return blk_rq_map_sg(mq->queue, mq->req, mq->sg);
> + if (!mq->bounce_buf) {
> + memset(mq->sg, 0, rq->nr_hw_segments * sizeof(struct
> scatterlist));
> + return blk_rq_map_sg(mq->queue, rq, mq->sg);
> + }
>
> BUG_ON(!mq->bounce_sg);
>
> - sg_len = blk_rq_map_sg(mq->queue, mq->req, mq->bounce_sg);
> + memset(mq->bounce_sg, 0, rq->nr_hw_segments * sizeof(struct
> scatterlist));
> + sg_len = blk_rq_map_sg(mq->queue, rq, mq->bounce_sg);
>
> mq->bounce_sg_len = sg_len;
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: > On Thu, 4 Oct 2007 12:38:05 +0200 > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > > > Is that a yes or a no? You said that the ->page field was involved > > > in > > > > It's a conditional yes, re-read it :-) > > > > I didn't get the memo about what chained sg entries entail. It's been posted here several times, but that's ok and it should not matter. I just can't answer your question with a clear yes or no, since it depends on certain situations. > > > list chaining, so does or doesn't it have to be initialized before a > > > call to sg_init_one()? > > > > That's not the problem. It has to be initialized before calling > > blk_rq_map_sg(). sg_init_one() will zero the entire sg entry, and that > > breaks if that particular sg entry is part of a larger sg table AND > > that sg entry happens to be the chain element. > > > > Ok, then it shouldn't affect my world at least. No, I think mmc is fine, it just needed that memset. > PS. Did someone forget to do a review of all blk_rq_map_sg() callers > before committing the chained list stuff? ;) Apparently this one got missed (and cciss), I'll do a new look just to be on the safe side. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 12:38:05 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > Is that a yes or a no? You said that the ->page field was involved > > in > > It's a conditional yes, re-read it :-) > I didn't get the memo about what chained sg entries entail. > > list chaining, so does or doesn't it have to be initialized before a > > call to sg_init_one()? > > That's not the problem. It has to be initialized before calling > blk_rq_map_sg(). sg_init_one() will zero the entire sg entry, and that > breaks if that particular sg entry is part of a larger sg table AND > that sg entry happens to be the chain element. > Ok, then it shouldn't affect my world at least. Rgds Pierre PS. Did someone forget to do a review of all blk_rq_map_sg() callers before committing the chained list stuff? ;) signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: > On Thu, 4 Oct 2007 11:30:14 +0200 > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > > > I assume sg_init_one() still can work on an uninitialized sg entry? > > > > Yes, but only if that sg entry is not part of a chained list. > > > > Is that a yes or a no? You said that the ->page field was involved in It's a conditional yes, re-read it :-) > list chaining, so does or doesn't it have to be initialized before a > call to sg_init_one()? That's not the problem. It has to be initialized before calling blk_rq_map_sg(). sg_init_one() will zero the entire sg entry, and that breaks if that particular sg entry is part of a larger sg table AND that sg entry happens to be the chain element. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 11:30:14 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > I assume sg_init_one() still can work on an uninitialized sg entry? > > Yes, but only if that sg entry is not part of a chained list. > Is that a yes or a no? You said that the ->page field was involved in list chaining, so does or doesn't it have to be initialized before a call to sg_init_one()? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: > On Thu, 4 Oct 2007 10:06:32 +0200 > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > > > Huh? Isn't the block layer supposed to fill in the entire thing? > > > (i.e. current contents shouldn't matter) > > > > Yeah, but sg chaining requires that ->page be filled in properly or it > > could confuse it. I think I'll add some debugging to catch that. > > > > I assume sg_init_one() still can work on an uninitialized sg entry? Yes, but only if that sg entry is not part of a chained list. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 10:06:32 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > Huh? Isn't the block layer supposed to fill in the entire thing? > > (i.e. current contents shouldn't matter) > > Yeah, but sg chaining requires that ->page be filled in properly or it > could confuse it. I think I'll add some debugging to catch that. > I assume sg_init_one() still can work on an uninitialized sg entry? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: > On Thu, 4 Oct 2007 09:25:15 +0200 > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > It looks like missing init of the sg list in mmc, does this work? > > > > Huh? Isn't the block layer supposed to fill in the entire thing? (i.e. > current contents shouldn't matter) Yeah, but sg chaining requires that ->page be filled in properly or it could confuse it. I think I'll add some debugging to catch that. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 09:25:15 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > > It looks like missing init of the sg list in mmc, does this work? > Huh? Isn't the block layer supposed to fill in the entire thing? (i.e. current contents shouldn't matter) Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Wed, 3 Oct 2007 23:16:59 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis <[EMAIL PROTECTED]> wrote: > > > OOPS followed by a 3 minute timeout, then completion of boot. > > Not seen if card (Kingston microSD adapter) is ejected; not seen in > > 2.6.23-rc8. Running on a Dell XPS M1330 laptop. > > Impossible! My code is bug free! > > [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160 > > [ 13.711857] Call Trace: > > [ 13.711971] [] mmc_queue_map_sg+0x28/0xc0 [mmc_block] > > [ 13.712085] [] mmc_blk_issue_rq+0x199/0x780 [mmc_block] > > [ 13.712193] [] mmc_queue_thread+0x78/0xe0 [mmc_block] Seems to be in the handling of the bounce buffer. I don't see how any of the parameters to blk_rq_map_sg() could be incorrect though, so I suspect the problem is not in the mmc layer. Don, is MMC_BLOCK_BOUNCE enabled? Could you try toggling it and see if things change? > > This could be due to git-block changes (or a lack of them ;)) > There are no pending patches, or recent changes that mess about in any real way in there. Don, when did this work last? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Wed, Oct 03 2007, Andrew Morton wrote:
> On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis <[EMAIL PROTECTED]> wrote:
>
> > OOPS followed by a 3 minute timeout, then completion of boot.
> > Not seen if card (Kingston microSD adapter) is ejected; not seen in
> > 2.6.23-rc8.
> > Running on a Dell XPS M1330 laptop.
> >
> > `dmesg` reports:
> >
> > [ 13.695045] mmcblk0: mmc0:e95c SD02G 1966080KiB
> > [ 13.695155] mmcblk0: p1
> > [ 13.706907] BUG: unable to handle kernel paging request at virtual
> > address 6b6b6b7a
> > [ 13.707026] printing eip: c01f09f0 *pde =
> > [ 13.707174] Oops: [#1] SMP
> > [ 13.707326] last sysfs file: /class/mmc_host/mmc0/mmc0:e95c/serial
> > [ 13.707389] Modules linked in: mmc_block sr_mod iwl4965 cdrom serio_raw
> > mac80211 piix sdhci pcspkr psmouse ide_core iTCO_wdt iTCO_vendor_support
> > watchdog_core watchdog_dev cfg80211 mmc_core shpchp pci_hotplug intel_agp
> > agpgart battery ac power_supply button evdev ata_generic ext3 jbd mbcache
> > sg sd_mod usbhid hid ahci ata_piix libata scsi_mod ohci1394 tg3 ieee1394
> > ehci_hcd uhci_hcd thermal processor fan fuse
> > [ 13.709649]
> > [ 13.709705] Pid: 4089, comm: mmcqd Not tainted (2.6.23-rc8-mm2 #27)
> > [ 13.709767] EIP: 0060:[] EFLAGS: 00010206 CPU: 0
> > [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160
> > [ 13.709889] EAX: 04b6a000 EBX: c4a030e0 ECX: 04b6b000 EDX: c100
> > [ 13.709951] ESI: 6b6b6b6a EDI: c11535d0 EBP: c4971e30 ESP: c4971df4
> > [ 13.710013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
> > [ 13.710074] Process mmcqd (pid: 4089, ti=c497 task=c387b660
> > task.ti=c497)
> > [ 13.710137] last branch before last exception/interrupt
> > [ 13.710249] from c0129bf8 (vprintk+0x1d8/0x340)
> > [ 13.710359] to c0129c9c (vprintk+0x27c/0x340)
> > [ 13.710453] Stack: c4971e08 c013d85f c48a0440 2000 04b6c000 c3914180
> > 0001 0001
> > [ 13.710920]1000 c4923700 0100 c48ca3a0 c48f6d88
> > c48f6d88 c4971e40
> > [ 13.711390]f8c39e58 c48f6d88 c4a9f020 c4971fbc f8c396c9 c017de04
> > 0004 c4971e84
> > [ 13.711857] Call Trace:
> > [ 13.711971] [] mmc_queue_map_sg+0x28/0xc0 [mmc_block]
> > [ 13.712085] [] mmc_blk_issue_rq+0x199/0x780 [mmc_block]
> > [ 13.712193] [] mmc_queue_thread+0x78/0xe0 [mmc_block]
> > [ 13.712309] [] kthread+0x42/0x70
> > [ 13.712415] [] kernel_thread_helper+0x7/0x14
> > [ 13.712523] ===
> > [ 13.712584] Code: 0c 03 4f 08 8b 7f 04 01 cf 89 7d d4 8b 3b 89 f8 29 d0
> > c1 f8 03 69 c0 39 8e e3 38 c1 e0 0c 03 43 08 39 45 d4 74 73 90 8d 74 26 00
> > <8b> 46 10 8d 4e 10 89 3e 89 c2 83 e2 fe a8 01 8b 45 e4 0f 45 ca
> > [ 13.71] EIP: [] blk_rq_map_sg+0xc0/0x160 SS:ESP
> > 0068:c4971df4
> > [ 13.845668] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1c0b1, caps:
> > 0xa04753/0x20
> > [ 13.879914] input: SynPS/2 Synaptics TouchPad as /class/input/input7
> > [ 192.162711] Adding 2731008k swap on /dev/sda7. Priority:-1 extents:1
> > across:2731008k
>
> This could be due to git-block changes (or a lack of them ;))
It looks like missing init of the sg list in mmc, does this work?
--- linux-2.6.23-rc8/drivers/mmc/card/queue.c~ 2007-10-04 09:22:02.0
+0200
+++ linux-2.6.23-rc8/drivers/mmc/card/queue.c 2007-10-04 09:23:13.0
+0200
@@ -334,14 +334,18 @@ static void copy_sg(struct scatterlist *
unsigned int mmc_queue_map_sg(struct mmc_queue *mq)
{
+ struct request *rq = mq->req;
unsigned int sg_len;
- if (!mq->bounce_buf)
- return blk_rq_map_sg(mq->queue, mq->req, mq->sg);
+ if (!mq->bounce_buf) {
+ memset(mq->sg, 0, rq->nr_hw_segments * sizeof(struct
scatterlist));
+ return blk_rq_map_sg(mq->queue, rq, mq->sg);
+ }
BUG_ON(!mq->bounce_sg);
- sg_len = blk_rq_map_sg(mq->queue, mq->req, mq->bounce_sg);
+ memset(mq->bounce_sg, 0, rq->nr_hw_segments * sizeof(struct
scatterlist));
+ sg_len = blk_rq_map_sg(mq->queue, rq, mq->bounce_sg);
mq->bounce_sg_len = sg_len;
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis <[EMAIL PROTECTED]> wrote: > OOPS followed by a 3 minute timeout, then completion of boot. > Not seen if card (Kingston microSD adapter) is ejected; not seen in > 2.6.23-rc8. > Running on a Dell XPS M1330 laptop. > > `dmesg` reports: > > [ 13.695045] mmcblk0: mmc0:e95c SD02G 1966080KiB > [ 13.695155] mmcblk0: p1 > [ 13.706907] BUG: unable to handle kernel paging request at virtual address > 6b6b6b7a > [ 13.707026] printing eip: c01f09f0 *pde = > [ 13.707174] Oops: [#1] SMP > [ 13.707326] last sysfs file: /class/mmc_host/mmc0/mmc0:e95c/serial > [ 13.707389] Modules linked in: mmc_block sr_mod iwl4965 cdrom serio_raw > mac80211 piix sdhci pcspkr psmouse ide_core iTCO_wdt iTCO_vendor_support > watchdog_core watchdog_dev cfg80211 mmc_core shpchp pci_hotplug intel_agp > agpgart battery ac power_supply button evdev ata_generic ext3 jbd mbcache sg > sd_mod usbhid hid ahci ata_piix libata scsi_mod ohci1394 tg3 ieee1394 > ehci_hcd uhci_hcd thermal processor fan fuse > [ 13.709649] > [ 13.709705] Pid: 4089, comm: mmcqd Not tainted (2.6.23-rc8-mm2 #27) > [ 13.709767] EIP: 0060:[] EFLAGS: 00010206 CPU: 0 > [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160 > [ 13.709889] EAX: 04b6a000 EBX: c4a030e0 ECX: 04b6b000 EDX: c100 > [ 13.709951] ESI: 6b6b6b6a EDI: c11535d0 EBP: c4971e30 ESP: c4971df4 > [ 13.710013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 > [ 13.710074] Process mmcqd (pid: 4089, ti=c497 task=c387b660 > task.ti=c497) > [ 13.710137] last branch before last exception/interrupt > [ 13.710249] from c0129bf8 (vprintk+0x1d8/0x340) > [ 13.710359] to c0129c9c (vprintk+0x27c/0x340) > [ 13.710453] Stack: c4971e08 c013d85f c48a0440 2000 04b6c000 c3914180 > 0001 0001 > [ 13.710920]1000 c4923700 0100 c48ca3a0 c48f6d88 > c48f6d88 c4971e40 > [ 13.711390]f8c39e58 c48f6d88 c4a9f020 c4971fbc f8c396c9 c017de04 > 0004 c4971e84 > [ 13.711857] Call Trace: > [ 13.711971] [] mmc_queue_map_sg+0x28/0xc0 [mmc_block] > [ 13.712085] [] mmc_blk_issue_rq+0x199/0x780 [mmc_block] > [ 13.712193] [] mmc_queue_thread+0x78/0xe0 [mmc_block] > [ 13.712309] [] kthread+0x42/0x70 > [ 13.712415] [] kernel_thread_helper+0x7/0x14 > [ 13.712523] === > [ 13.712584] Code: 0c 03 4f 08 8b 7f 04 01 cf 89 7d d4 8b 3b 89 f8 29 d0 c1 > f8 03 69 c0 39 8e e3 38 c1 e0 0c 03 43 08 39 45 d4 74 73 90 8d 74 26 00 <8b> > 46 10 8d 4e 10 89 3e 89 c2 83 e2 fe a8 01 8b 45 e4 0f 45 ca > [ 13.71] EIP: [] blk_rq_map_sg+0xc0/0x160 SS:ESP 0068:c4971df4 > [ 13.845668] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1c0b1, caps: > 0xa04753/0x20 > [ 13.879914] input: SynPS/2 Synaptics TouchPad as /class/input/input7 > [ 192.162711] Adding 2731008k swap on /dev/sda7. Priority:-1 extents:1 > across:2731008k This could be due to git-block changes (or a lack of them ;)) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
> On Tue, 2 Oct 2007, Ilpo Järvinen wrote: > > > I'm currently out of ideas where it could come from... Hmm, there seems to be off-by-one in tcp_retrans_try_collapse after all, or in fact, two of them. I'll post patch for this tomorrow... -- i.
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
> 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.
In case you haven't yet get started (or it's easy enough to replace),
please use the one below instead (I forgot one counter from printout
in the last patch, which might turn out useful...).
--
i.
---
include/net/tcp.h |3 +
net/ipv4/tcp_input.c | 23 +--
net/ipv4/tcp_ipv4.c | 103 +
net/ipv4/tcp_output.c |6 ++-
4 files changed, 129 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
+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;
tp->highest_sack = tp->snd_una;
}
@@ -1420,6 +1422,7 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff
*ack_skb, u32 prior_snd_
}
}
}
+ tcp_verify_fackets(sk);
/* Check for lost retransmit. This superb idea is
* borrowed from "ratehalving". Event "C".
@@ -1632,13 +1635,14 @@ void tcp_enter_frto(struct sock *sk)
tcp_set_ca_state(sk, TCP_CA_Disorder);
tp->high_seq = tp->snd_nxt;
tp->frto_counter = 1;
+ tcp_verify_fackets(sk);
}
/* Enter Loss state after F-RTO was applied. Dupack arrived after RTO,
* which indicates that we should follow the traditional RTO recovery,
* i.e. mark everything lost and do go-back-N retransmission.
*/
-static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int
flag)
+void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
{
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
@@ -1675,6 +1679,7 @@ static void tcp_enter_frto_loss(struct sock *sk, int
allowed_segments, int flag)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp->snd_cwnd = tcp_packets_in_flight(tp) + allowed_segments;
tp->snd_cwnd_cnt = 0;
@@ -1753,6 +1758,7 @@ void tcp_enter_loss(struct sock *sk, int how)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp->reordering = min_t(unsigned int, tp->reordering,
sysctl_tcp_reordering);
@@ -2308,7 +2314,7 @@ static void tcp_mtup_probe_success(struct sock *sk,
struct sk_buff *skb)
* It does _not_ decide what to send, it is made in function
* tcp_xmit_retransmit_queue().
*/
-static void
+void
tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
{
struct inet_connection_sock *icsk = inet_csk(sk);
@@ -2322,8 +2328,11 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
int flag)
if (!tp->packets_out)
tp->sacked_out = 0;
- if (WARN_ON(!tp->sacked_out && tp->fackets_out))
+ if (WARN_ON(!tp->sacked_out && tp->fackets_out)) {
+ printk(KERN_ERR "TCP %d\n", tcp_is_reno(tp));
+ tcp_print_queue(sk);
tp->fackets_out = 0;
+ }
/* Now state machine starts.
* A. ECE, hence prohibit cwnd undoing, the reduction is required. */
@@ -2333,6 +2342,8 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
int flag)
/* B. In all the states check for reneging SACKs. */
if (tp->sacked_out && tcp_check_sack_reneging(sk))
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
On Mon, 1 Oct 2007, Cedric Le Goater wrote:
> 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:
>[] tcp_ack+0xcd6/0x18af
[...snip...]
>
> TCP 0
Hmm, so it's SACK then...
> 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.
>
> I'm trying to get the WARNING and the tcpdump output for it but for the
> moment, it seems it's beyond my reach :/
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
+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;
tp->highest_sack = tp->snd_una;
}
@@ -1420,6 +1422,7 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff
*ack_skb, u32 prior_snd_
}
}
}
+ tcp_verify_fackets(sk);
/* Check for lost retransmit. This superb idea is
* borrowed from "ratehalving". Event "C".
@@ -1632,13 +1635,14 @@ void tcp_enter_frto(struct sock *sk)
tcp_set_ca_state(sk, TCP_CA_Disorder);
tp->high_seq = tp->snd_nxt;
tp->frto_counter = 1;
+ tcp_verify_fackets(sk);
}
/* Enter Loss state after F-RTO was applied. Dupack arrived after RTO,
* which indicates that we should follow the traditional RTO recovery,
* i.e. mark everything lost and do go-back-N retransmission.
*/
-static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int
flag)
+void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
{
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
@@ -1675,6 +1679,7 @@ static void tcp_enter_frto_loss(struct sock *sk, int
allowed_segments, int flag)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp->snd_cwnd = tcp_packets_in_flight(tp) + allowed_segments;
tp->snd_cwnd_cnt = 0;
@@ -1753,6 +1758,7 @@ void tcp_enter_loss(struct sock *sk, int how)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp->reordering = min_t(unsigned int, tp->reordering,
sysctl_tcp_reordering);
@@ -2308,7 +2314,7 @@ static void tcp_mtup_probe_success(struct sock *sk,
struct sk_buff *skb)
* It does _not_ decide what to send, it is made in function
* tcp_xmit_retransmit_queue().
*/
-static void
+void
tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
{
struct inet_connection_sock *icsk = inet_csk(sk);
@@ -2322,8 +2328,11 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
int flag)
if (!tp->packets_out)
tp->sacked_out = 0;
- if (WARN_ON(!tp->sacked_out && tp->fackets_out))
+ if (WARN_ON(!tp->sacked_out && tp->fackets_out)) {
+ printk(KERN_ERR "TCP %d\n", tcp_is_reno(tp));
+
Re: 2.6.23-rc8-mm2
On Sun, 30 Sep 2007 22:01:43 +0200, "Rafael J. Wysocki" said: > On Sunday, 30 September 2007 10:50, Andrew Morton wrote: > > On Sat, 29 Sep 2007 22:26:21 -0400 [EMAIL PROTECTED] wrote: > > > > > On Thu, 27 Sep 2007 02:22:20 PDT, Andrew Morton said: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ > > > > > > 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. > > http://lkml.org/lkml/2007/9/27/322, perhaps? 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. pgpNuwI7EGT7J.pgp Description: PGP signature
Re: 2.6.23-rc8-mm2
On Sun, 30 Sep 2007 01:50:14 PDT, Andrew Morton said: > On Sat, 29 Sep 2007 22:26:21 -0400 [EMAIL PROTECTED] wrote: > > > On Thu, 27 Sep 2007 02:22:20 PDT, Andrew Morton said: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ > > > > 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. 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 <[EMAIL PROTECTED]> 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 df912ea4ae7233d1504fbd861ee127bd7ee5781d And diffing the 2 trees (linus -git and my "origin.patch" tree shows only the following 2 differences: commit f7f847b01571e86044dc77e03d92f43699652f8d Author: Linus Torvalds <[EMAIL PROTECTED]> Date: Wed Sep 26 15:21:33 2007 -0700 Revert "x86-64: Disable local APIC timer use on AMD systems with C1E" commit 2efa33f81ef56e7700c09a3d8a881c96692149e5 Author: H. Peter Anvin <[EMAIL PROTECTED]> Date: Wed Sep 26 14:11:43 2007 -0700 [x86 setup] Handle case of improperly terminated E820 chain So I'm having a pretty good case of WTF? going at the moment... pgpcIPnnfgoO3.pgp Description: PGP signature
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
Ilpo Järvinen wrote: > On Sat, 29 Sep 2007, Cedric Le Goater wrote: > >> Ilpo Järvinen wrote: >>> On Fri, 28 Sep 2007, Ilpo Järvinen wrote: On Fri, 28 Sep 2007, Cedric Le Goater wrote: > I just found that warning in my logs. It seems that it's been > happening since rc7-mm1 at least. > > WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 > tcp_fastretrans_alert() > > Call Trace: >[] tcp_ack+0xcd6/0x1894 > ...snip... ...Thanks for the report, I'll have look what could still break fackets_out... >>> I think this one is now clear to me, tcp_fragment/collapse adjusts >>> fackets_out (incorrectly) also for reno flow when there were some dupACKs >>> that made sacked_out != 0. Could you please try if patch below proves all >>> them to be of non-SACK origin... In case that's true, it's rather >>> harmless, I'll send a fix on Monday or so (this would anyway be needed)... >>> If you find out that them occur with SACK enabled flow, that would be >>> more interesting and requires more digging... >> I'm trying now to reproduce this WARNING. >> >> It seems that the n/w behaves differently during the week ends. Probably >> taking a break. > > Thanks. > > Of course there are other means too to determine if TCP flows do negotiate > SACK enabled or not. Depending on your test case (which is fully unknown > to me) they may or may not be usable... At least the value of tcp_sack > sysctl on both systems or tcpdump catching SYN packets should give that > detail. ...If you know to which hosts TCP could be connected (and active) > to, while the WARNING triggers, it's really easy to test what is being > negotiated as it's unlikely to change at short notice and any TCP flow to > that host will get us the same information though the WARNING would not be > triggered with it at this time. Obviously if at least one of the remotes > is not known or the set ends up being mixture of reno and SACK flows, then > we'll just have to wait and see which fish we get... 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: [] tcp_ack+0xcd6/0x18af [] tcp_rcv_established+0x61f/0x6df [] __lock_acquire+0x8a1/0xf1b [] tcp_v4_do_rcv+0x3e/0x394 [] tcp_v4_rcv+0x61c/0x9a9 [] ip_local_deliver+0x1da/0x2a4 [] ip_rcv+0x583/0x5c9 [] packet_rcv_spkt+0x19a/0x1a8 [] netif_receive_skb+0x2cf/0x2f5 [] :tg3:tg3_poll+0x65d/0x8a4 [] net_rx_action+0xb8/0x191 [] __do_softirq+0x5f/0xe0 [] call_softirq+0x1c/0x28 [] do_softirq+0x3b/0xb8 [] irq_exit+0x4e/0x50 [] do_IRQ+0xbd/0xd7 [] mwait_idle+0x0/0x4d [] ret_from_intr+0x0/0xf [] mwait_idle+0x43/0x4d [] enter_idle+0x22/0x24 [] cpu_idle+0x9d/0xc0 [] rest_init+0x55/0x57 [] start_kernel+0x2d6/0x2e2 [] _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 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 the moment, it seems it's beyond my reach :/ Hope it helps ! C. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Mon, 1 Oct 2007 02:07:33 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > > That excludes all the extra stuff in -mm and should give us a good hint > > whether HPET is really at fault. > > The system does boot with rc8 + hrt1. > > Andrew: any suggestions on how to trace the "real" culprit for the hang? Not really. Ordinarily one could move hpet-force-enable-on-ich34.patch to start-of-series, then verify that mainline+hpet-force-enable-on-ich34.patch works correctly, then just bisect all the other patches. But tht doesn't work because hpet-force-enable-on-ich34.patch has a dependency on other patches in the hrt-related patch series, and it could be that the bug which you've exposed is already in mainline anyway. If you had a minimal, standalone hpet-force-enable-on-ich34.patch against mainline then you could test that against mainline. If that also failed then you could git-bisect mainline, applying hpet-force-enable-on-ich34.patch each time (I've done that before). But this assumes that you're searching for a regression in minaline. It may never have worked. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Monday 01 October 2007, Udo A. Steinberg wrote: > On Mon, 1 Oct 2007 02:07:33 +0200 Frans Pop (FP) wrote: > FP> On Monday 01 October 2007, you wrote: > FP> > I was suggesting to download 2.6.23-rc8 and applying the -hrt > patchset FP> > at > FP> > > http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23-rc8/ > FP> > on top of it. > > FP> The system does boot with rc8 + hrt1. > > FP> Udo: I did see one issue during boot with this rc8 + hrt1 kernel. > FP> System is Debian unstable. > FP> Setting the system clock.. > FP> select() to /dev/rtc to wait for clock tick timed out > > Thomas and Andrew are the best people to ask about what exactly has been > merged from -hrt into -mm. Maybe they can chime in here. I agree with you for the original issue. But the /dev/rtc issue described here has *nothing* to do with mm: I saw that with pure Linus' 2.6.23-rc8 + Thomas' hrt1 on top: the combination you asked me to test. So this is an issue in "your" hrt changes. Thomas may have some suggestions, but maybe you can have a look as well? I'm of course willing to do a bisect if needed to narrow this down, but I'd like to know who I'll be talking or where I should follow up for issues in the hrt patch set. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Mon, 1 Oct 2007 02:07:33 +0200 Frans Pop (FP) wrote: FP> On Monday 01 October 2007, you wrote: FP> > I was suggesting to download 2.6.23-rc8 and applying the -hrt patchset FP> > at FP> > http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23-rc8/ FP> > on top of it. FP> FP> Ah, OK. I'm afraid that was not at all clear from your previous FP> message :-/ Yeah, sorry about that. FP> During 'make oldconfig' I got a config question about "CPU idle FP> support", which does not seem to be in rc8-mm2; is that correct? I FP> answered N. Shouldn't matter either way. Answering 'Y' gives you a more sophisticated C-state governor that improves battery life. FP> The system does boot with rc8 + hrt1. Good. That seems to confirm my suspicion that the real problem is caused by something in -mm which is not in -hrt. However, I have no idea what exactly could be going wrong. FP> Andrew: any suggestions on how to trace the "real" culprit for the hang? FP> FP> FP> Udo: I did see one issue during boot with this rc8 + hrt1 kernel. FP> System is Debian unstable. FP> Setting the system clock.. FP> select() to /dev/rtc to wait for clock tick timed out Thomas and Andrew are the best people to ask about what exactly has been merged from -hrt into -mm. Maybe they can chime in here. Cheers, - Udo signature.asc Description: PGP signature
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Monday 01 October 2007, you wrote: > On Sun, 30 Sep 2007 23:50:29 +0200 Frans Pop (FP) wrote: > > I'm not sure what you mean. I fetched the branch I think you referred > > to [1], but when I did a merge of that on top of v2.6.23-rc8-mm2 I > > got "Already up-to-date", so AFAICT that branch is fully merged into mm > > and I'm already running with you latest code... > > I was suggesting to download 2.6.23-rc8 and applying the -hrt patchset at > http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23-rc8/ > on top of it. Ah, OK. I'm afraid that was not at all clear from your previous message :-/ During 'make oldconfig' I got a config question about "CPU idle support", which does not seem to be in rc8-mm2; is that correct? I answered N. > That excludes all the extra stuff in -mm and should give us a good hint > whether HPET is really at fault. The system does boot with rc8 + hrt1. Andrew: any suggestions on how to trace the "real" culprit for the hang? Udo: I did see one issue during boot with this rc8 + hrt1 kernel. System is Debian unstable. Setting the system clock.. select() to /dev/rtc to wait for clock tick timed out Also, if the patchset really is not the same as in mm, then that at least partially invalidates this test. Relevant lines from dmesg diff: -Linux version 2.6.23-rc6 [...] +Linux version 2.6.23-rc8-hrt1 [...] [...] +hpet clockevent registered +hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 +hpet0: 3 64-bit timers, 14318180 Hz ACPI: RTC can wake from S4 Time: tsc clocksource has been installed. [...] -Marking TSC unstable due to: possible TSC halt in C2. -Time: acpi_pm clocksource has been installed. [...] -Clocksource tsc unstable (delta = -473964036 ns) [...] Real Time Clock Driver v1.12ac [...] +Marking TSC unstable due to: cpufreq changes. +Time: hpet clocksource has been installed. +Clocksource tsc unstable (delta = -125526392 ns) # cat /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm pit jiffies tsc # cat /sys/devices/system/clocksource/clocksource0/current_clocksource hpet I noted that acpi_pm is no longer mentioned in dmesg, but is still present. Cheers, FJP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc8-mm2] Fails to resume from s2mem (was:kernel BUG at mm/slab.c:591! ...)
On Sunday 30 September 2007, you wrote: > On Sun, 30 Sep 2007 00:15:35 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > > On Friday 28 September 2007, you wrote: > > > My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot after: > > > > With 'hpet-force-enable-on-ich34' reverted the system boots OK again. > > > > We're not yet done though. It now fails to resume from suspend > > suspend-to-RAM? Can you describe this failure a bit more? The suspend is done from KDE by closing the lid, which runs a trivial script. The system seems to suspend normally (correct leds at the end). When I open the lid again, the system seems to restart (fan starts, leds change), but the LCD only shows: L System cannot be reached over the net. After some time the fans speed up. Exactly the same happens if I 'echo mem /sys/power/state' from console without X running. BTW, that partial display is normal for me: I mostly see "Linu" until the switch to X.Org, but never a full sentence that makes sense. *Is* that normal? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc8-mm2] kernel BUG at mm/slab.c:591! | invalid opcode: 0000 [#1] SMP
> > +Call Trace: > > + [] kobject_cleanup+0x31/0x47 > > + [] kref_put+0x76/0x84 > > + [] fuse_sysfs_cleanup+0xa/0x14 [fuse] > > + [] fuse_exit+0x19/0x24 [fuse] > > + [] sys_delete_module+0x1c0/0x228 > > + [] sysenter_past_esp+0x6b/0xa1 > > + [] 0xe410 > > + === > > +Code: aa 43 c0 8b 02 25 00 40 02 00 3d 00 40 02 00 75 03 8b 52 0c 8b 02 25 > > 00 40 02 00 3d 00 40 02 00 75 03 8b 52 0c 8b 02 84 c0 78 04 <0f> 0b eb fe > > 8b 4a 18 64 a1 08 00 40 c0 8b 1c 81 8b 03 3b 43 04 > > +EIP: [] kfree+0x5e/0x97 SS:ESP 0068:c7205f14 > > > > I think we have now fixed that - Miklos, do you recall? Yes, Greg has a fix. I didn't see it go into -mm yet. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Sun, 30 Sep 2007 23:50:29 +0200 Frans Pop (FP) wrote: FP> I'm not sure what you mean. I fetched the branch I think you referred to FP> [1], but when I did a merge of that on top of v2.6.23-rc8-mm2 I FP> got "Already up-to-date", so AFAICT that branch is fully merged into mm FP> and I'm already running with you latest code... FP> Please correct me if I'm doing anything wrong. I was suggesting to download 2.6.23-rc8 and applying the -hrt patchset at http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23-rc8/ on top of it. That excludes all the extra stuff in -mm and should give us a good hint whether HPET is really at fault. Cheers, - Udo signature.asc Description: PGP signature
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Sunday 30 September 2007, you wrote: > On Sat, 29 Sep 2007 13:02:34 -0700 Andrew Morton (AM) wrote: > AM> On Sat, 29 Sep 2007 21:40:22 +0200 Frans Pop wrote: > AM> > 3fe6c0016fd863b233097a8219a0d8577c2fd503 is first bad commit > AM> > commit 3fe6c0016fd863b233097a8219a0d8577c2fd503 > AM> > Author: Udo A. Steinberg <...> > AM> > hpet-force-enable-on-ich34 > AM> > > AM> > Guess the comments about thin ice and testing were justified :-) > AM> > > AM> Great, thanks for doing that. > AM> > AM> I guess I'll drop the patch for now in that case. > > I somehow doubt that the HPET patch itself is the culprit. In fact, the > reason it shows up on git-bisect is probably because without it HPET > functionality is not enabled on the platform. So the problem could really > be anywhere in the HPET-driven timer infrastructure. > > Frans, could you try out the -hrt patchset from Thomas Gleixner and see > if that works? I'm not sure what you mean. I fetched the branch I think you referred to [1], but when I did a merge of that on top of v2.6.23-rc8-mm2 I got "Already up-to-date", so AFAICT that branch is fully merged into mm and I'm already running with you latest code... Please correct me if I'm doing anything wrong. [1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-hrt > Also, what ICH does your platform have? ICH3 or ICH4? It is ICH4. See the link below (which I already included) for more details: > AM> > lspci and a 2.6.23-rc6 dmesg for this system can be found in: > AM> > http://lkml.org/lkml/2007/9/19/300 Cheers, FJP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2
On Sunday, 30 September 2007 10:50, Andrew Morton wrote: > On Sat, 29 Sep 2007 22:26:21 -0400 [EMAIL PROTECTED] wrote: > > > On Thu, 27 Sep 2007 02:22:20 PDT, Andrew Morton said: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ > > > > 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. http://lkml.org/lkml/2007/9/27/322, perhaps? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Sat, 29 Sep 2007 13:02:34 -0700 Andrew Morton (AM) wrote: AM> On Sat, 29 Sep 2007 21:40:22 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: AM> AM> > On Saturday 29 September 2007, you wrote: AM> > > On Sat, 29 Sep 2007 02:32:44 +0200 Frans Pop <[EMAIL PROTECTED]> AM> > > wrote: AM> > > > On Friday 28 September 2007, Frans Pop wrote: AM> > > > > My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot AM> > > > > after: Marking TSC unstable due to: possible TSC halt in C2. AM> > > > > Time: acpi_pm clocksource has been installed. AM> > > > AM> > > > A few new boot attempts show the problem is more likely at: AM> > > > Probing IDE interface ide0... AM> > AM> > Looks like it is both: hpet killing IDE? AM> > AM> > > Two iterations should get you into the culprit zone. AM> > AM> > Thanks for the pointers. Luckily I ended up in a quite narrow zone AM> > between two of the points you indicated (10 iterations). AM> > AM> > And the winner is: AM> > AM> > 3fe6c0016fd863b233097a8219a0d8577c2fd503 is first bad commit AM> > commit 3fe6c0016fd863b233097a8219a0d8577c2fd503 AM> > Author: Udo A. Steinberg <...> AM> > hpet-force-enable-on-ich34 AM> > AM> > Guess the comments about thin ice and testing were justified :-) AM> > AM> > lspci and a 2.6.23-rc6 dmesg for this system can be found in: AM> > http://lkml.org/lkml/2007/9/19/300 AM> AM> Great, thanks for doing that. AM> AM> I guess I'll drop the patch for now in that case. I somehow doubt that the HPET patch itself is the culprit. In fact, the reason it shows up on git-bisect is probably because without it HPET functionality is not enabled on the platform. So the problem could really be anywhere in the HPET-driven timer infrastructure. Frans, could you try out the -hrt patchset from Thomas Gleixner and see if that works? Also, what ICH does your platform have? ICH3 or ICH4? Cheers, - Udo signature.asc Description: PGP signature
Re: [2.6.23-rc8-mm2] kernel BUG at mm/slab.c:591! | invalid opcode: 0000 [#1] SMP
On Sun, 30 Sep 2007 00:15:35 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > On Friday 28 September 2007, you wrote: > > My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot after: > > With 'hpet-force-enable-on-ich34' reverted the system boots OK again. > > We're not yet done though. It now fails to resume from suspend suspend-to-RAM? Can you describe this failure a bit more? > and there's > also the BUG (see subject) during power off. Possibly these are related. > > Attached a diff of dmesg between 2.6.23-6 and 2.6.23-8. Nothing spectacular > AFAICT, except that I activated netconsole. > > The details of that BUG are at the end of the diff. > > I have some idea where to start looking for this one. If I'm not mistaken, > it should be somewhere between these two changes: > # good: [01762341418efa818f28dc69426ca7cc582cdc8c] git-wireless > # good: [ecdd2a3cb73af8b4659a4cb150bdf2a3ac908791] > i386-pit-remove-the-useless-ifdefs > > +[ cut here ] > +kernel BUG at mm/slab.c:591! > +invalid opcode: [#1] SMP > +last sysfs file: /devices/pci:00/:00:1e.0/:01:0b.0/resource > +Modules linked in: ipv6 fuse dm_snapshot eeprom lm90 i2c_i801 i2c_core > speedstep_ich speedstep_lib toshiba_acpi joydev tsdev pcmcia firmware_class > snd_intel8x0 snd_intel8x0m snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss > yenta_socket snd_pcm rsrc_nonstatic pcmcia_core snd_timer iTCO_wdt video > output snd battery psmouse ac watchdog_core watchdog_dev button parport_pc > parport shpchp pci_hotplug soundcore snd_page_alloc intel_agp agpgart evdev > serio_raw pcspkr rtc ext3 jbd mbcache dm_mirror dm_mod ide_cd cdrom ide_disk > piix generic ide_core ata_generic libata scsi_mod ehci_hcd uhci_hcd usbcore > thermal processor fan > + > +Pid: 3763, comm: rmmod Not tainted (2.6.23-rc8-mm2 #1) > +EIP: 0060:[] EFLAGS: 00010046 CPU: 0 > +EIP is at kfree+0x5e/0x97 > +EAX: EBX: dfe704b8 ECX: c2340d84 EDX: c13fcd40 > +ESI: 0286 EDI: dfe6ac65 EBP: c7204000 ESP: c7205f14 > + DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > +Process rmmod (pid: 3763, ti=c7204000 task=c201eab0 task.ti=c7204000) > +last branch before last exception/interrupt > + from c016df66 (kfree+0x53/0x97) > + to c016df6b (kfree+0x58/0x97) > +Stack: dfe704b8 dfe6ac65 dfe704c8 c01d975c dfe7048c c01d9772 0880 > c01da45a > + 0880 dfe70488 dfe705c0 dfe69395 > dfe6a5f2 > + dfe6aba0 c01465a0 65737566 c21e75c0 c0163e91 > c18df200 > +Call Trace: > + [] kobject_cleanup+0x31/0x47 > + [] kref_put+0x76/0x84 > + [] fuse_sysfs_cleanup+0xa/0x14 [fuse] > + [] fuse_exit+0x19/0x24 [fuse] > + [] sys_delete_module+0x1c0/0x228 > + [] sysenter_past_esp+0x6b/0xa1 > + [] 0xe410 > + === > +Code: aa 43 c0 8b 02 25 00 40 02 00 3d 00 40 02 00 75 03 8b 52 0c 8b 02 25 > 00 40 02 00 3d 00 40 02 00 75 03 8b 52 0c 8b 02 84 c0 78 04 <0f> 0b eb fe 8b > 4a 18 64 a1 08 00 40 c0 8b 1c 81 8b 03 3b 43 04 > +EIP: [] kfree+0x5e/0x97 SS:ESP 0068:c7205f14 > I think we have now fixed that - Miklos, do you recall? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2 - PowerPC link failure at arch/powerpc/kernel/head_64.o
Kamalesh Babulal wrote: > 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 > Adding CC to the powerpc mailing list -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2
On Sat, 29 Sep 2007 22:26:21 -0400 [EMAIL PROTECTED] wrote: > On Thu, 27 Sep 2007 02:22:20 PDT, Andrew Morton said: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ > > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2
From: Greg KH <[EMAIL PROTECTED]> Date: Sat, Sep 29, 2007 at 08:19:42AM -0700 > On Sat, Sep 29, 2007 at 05:37:29PM +0800, Dave Young wrote: > > Hi, > > The kernel report warnings about sysfs filename duplicate under > > rc8-mm1 and rc8-mm2. > > 1. > > cut > > sysfs: duplicate filename 'usbcore' can not be created > > WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() > > [] dump_trace+0x1bf/0x1d0 > > [] show_trace_log_lvl+0x18/0x30 > > [] show_trace+0xf/0x20 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: [] sysfs_add_one+0xac/0xe0 [] sysfs_create_link+0xac/0x140 [] device_rename+0x1c2/0x220 [] dev_change_name+0xbc/0x250 [] dev_ifsioc+0x338/0x3a0 [] dev_ioctl+0x36d/0x3c0 [] handle_mm_fault+0x1a5/0x6f0 [] sock_ioctl+0x7d/0x250 [] do_ioctl+0x31/0x90 [] vfs_ioctl+0x21b/0x2d0 [] sys_ioctl+0x4a/0x80 [] 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: [] sysfs_add_one+0xac/0xe0 [] sysfs_create_link+0xac/0x140 [] device_rename+0x1c2/0x220 [] dev_change_name+0xbc/0x250 [] dev_ifsioc+0x338/0x3a0 [] dev_ioctl+0x36d/0x3c0 [] handle_mm_fault+0x1a5/0x6f0 [] sock_ioctl+0x7d/0x250 [] do_ioctl+0x31/0x90 [] vfs_ioctl+0x21b/0x2d0 [] sys_ioctl+0x4a/0x80 [] 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: sysfs_create_symlink failed (-17) ip_tables: (C) 2000-2006 Netfilter Core Team .config attached below. Kind regards, Jurriaan # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Sat Sep 29 07:37:07 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_NONIRQ_WAKEUP=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set 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=y 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=18 # 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 set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not
Re: 2.6.23-rc8-mm2 - PowerPC link failure at arch/powerpc/kernel/head_64.o
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2
On Thu, 27 Sep 2007 02:22:20 PDT, Andrew Morton said: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ 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. pgpHvQvpzYjP1.pgp Description: PGP signature
Re: 2.6.23-rc8-mm2
>On 9/29/07, Greg KH <[EMAIL PROTECTED]> wrote: > On Sat, Sep 29, 2007 at 05:37:29PM +0800, Dave Young wrote: > > 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() > > [] dump_trace+0x1bf/0x1d0 > > [] show_trace_log_lvl+0x18/0x30 > > [] show_trace+0xf/0x20 > > [] dump_stack+0x12/0x20 > > [] sysfs_add_one+0xa0/0xe0 > > [] create_dir+0x48/0xb0 > > [] sysfs_create_dir+0x29/0x50 > > [] create_dir+0x1b/0x50 > > [] kobject_add+0x46/0x150 > > [] kernel_param_sysfs_setup+0x50/0xb0 > > [] param_sysfs_builtin+0xee/0x130 > > [] param_sysfs_init+0x24/0x60 > > [] do_initcalls+0x46/0x1e0 > > [] kernel_init+0x62/0xb0 > > [] 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. > > That is very wierd, do you have both USB built in and as a module > somehow? 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 set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_LSF=y CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_PREEMPT_NOTIFIERS=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # 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 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MCORE2 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CO
Re: [2.6.23-rc8-mm2] kernel BUG at mm/slab.c:591! | invalid opcode: 0000 [#1] SMP
On Friday 28 September 2007, you wrote: > My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot after: With 'hpet-force-enable-on-ich34' reverted the system boots OK again. We're not yet done though. It now fails to resume from suspend and there's also the BUG (see subject) during power off. Possibly these are related. Attached a diff of dmesg between 2.6.23-6 and 2.6.23-8. Nothing spectacular AFAICT, except that I activated netconsole. The details of that BUG are at the end of the diff. I have some idea where to start looking for this one. If I'm not mistaken, it should be somewhere between these two changes: # good: [01762341418efa818f28dc69426ca7cc582cdc8c] git-wireless # good: [ecdd2a3cb73af8b4659a4cb150bdf2a3ac908791] i386-pit-remove-the-useless-ifdefs Cheers, FJP --- 2.6.23-rc6-686.dmesg 2007-09-19 19:32:00.0 +0200 +++ strider2.log 2007-09-29 23:55:18.0 +0200 @@ -1,335 +1,360 @@ -Linux version 2.6.23-rc6 ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-4)) #1 SMP Wed Sep 19 16:31:00 CEST 2007 +Linux version 2.6.23-rc8-mm2 ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-4)) #1 SMP Sat Sep 29 23:22:39 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 000eee00 (reserved) BIOS-e820: 000eee00 - 000ef000 (ACPI NVS) BIOS-e820: 000ef000 - 0010 (reserved) BIOS-e820: 0010 - 1ef4 (usable) BIOS-e820: 1ef4 - 1ef5 (ACPI data) BIOS-e820: 1ef5 - 1f00 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fec1 - fec2 (reserved) BIOS-e820: feda - fedc (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - ffc0 (reserved) BIOS-e820: ffe8 - 0001 (reserved) 0MB HIGHMEM available. 495MB LOWMEM available. -Entering add_active_range(0, 0, 126784) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 126784 HighMem126784 -> 126784 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 126784 -On node 0 totalpages: 126784 - DMA zone: 32 pages used for memmap - DMA zone: 0 pages reserved - DMA zone: 4064 pages, LIFO batch:0 - Normal zone: 958 pages used for memmap - Normal zone: 121730 pages, LIFO batch:31 - HighMem zone: 0 pages used for memmap - Movable zone: 0 pages used for memmap DMI 2.3 present. ACPI: RSDP 000F0180, 0014 (r0 TOSHIB) ACPI: RSDT 1EF4, 0038 (r1 TOSHIB 750970814 TASM 401) ACPI: FACP 1EF40060, 0084 (r2 TOSHIB 750 20030101 TASM 401) ACPI: DSDT 1EF40558, 4B72 (r1 TOSHIB A000C20031216 MSFT 10E) ACPI: FACS 000EEE00, 0040 ACPI: SSDT 1EF402CA, 0082 (r1 TOSHIB A000C20030917 MSFT 10E) ACPI: DBGP 1EF400E4, 0034 (r1 TOSHIB 750970814 TASM 401) ACPI: BOOT 1EF40038, 0028 (r1 TOSHIB 750970814 TASM 401) ACPI: APIC 1EF40118, 0062 (r1 TOSHIB 750970814 TASM 401) ACPI: PM-Timer IO Port: 0xd808 -ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) -ACPI: IRQ0 used by override. -ACPI: IRQ2 used by override. -ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 2000 (gap: 1f00:dfc0) swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000e swsusp: Registered nosave memory region: 000e - 000ee000 swsusp: Registered nosave memory region: 000ee000 - 000ef000 swsusp: Registered nosave memory region: 000ef000 - 0010 -Built 1 zonelists in Zone order. Total pages: 125794 -Kernel command line: root=/dev/hda3 ro vga=791 -mapped APIC to b000 (fee0) -mapped IOAPIC to a000 (fec0) +Built 1 zonelists in Zone order, mobility grouping on. Total pages: 125794 +Kernel command line: root=/dev/hda3 resume=/dev/hda6 ro vga=791 [EMAIL PROTECTED]/,@10.19.66.12/ Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) -Detected 2793.139 MHz processor. +Detected 2793.094 MHz p
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
On Sat, 29 Sep 2007, Cedric Le Goater wrote: > Ilpo Järvinen wrote: > > On Fri, 28 Sep 2007, Ilpo Järvinen wrote: > >> On Fri, 28 Sep 2007, Cedric Le Goater wrote: > >> > >>> I just found that warning in my logs. It seems that it's been > >>> happening since rc7-mm1 at least. > >>> > >>> WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 > >>> tcp_fastretrans_alert() > >>> > >>> Call Trace: > >>>[] tcp_ack+0xcd6/0x1894 > >>> ...snip... > >> ...Thanks for the report, I'll have look what could still break > >> fackets_out... > > > > I think this one is now clear to me, tcp_fragment/collapse adjusts > > fackets_out (incorrectly) also for reno flow when there were some dupACKs > > that made sacked_out != 0. Could you please try if patch below proves all > > them to be of non-SACK origin... In case that's true, it's rather > > harmless, I'll send a fix on Monday or so (this would anyway be needed)... > > If you find out that them occur with SACK enabled flow, that would be > > more interesting and requires more digging... > > I'm trying now to reproduce this WARNING. > > It seems that the n/w behaves differently during the week ends. Probably > taking a break. Thanks. Of course there are other means too to determine if TCP flows do negotiate SACK enabled or not. Depending on your test case (which is fully unknown to me) they may or may not be usable... At least the value of tcp_sack sysctl on both systems or tcpdump catching SYN packets should give that detail. ...If you know to which hosts TCP could be connected (and active) to, while the WARNING triggers, it's really easy to test what is being negotiated as it's unlikely to change at short notice and any TCP flow to that host will get us the same information though the WARNING would not be triggered with it at this time. Obviously if at least one of the remotes is not known or the set ends up being mixture of reno and SACK flows, then we'll just have to wait and see which fish we get... -- i.
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Sat, 29 Sep 2007 21:40:22 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > On Saturday 29 September 2007, you wrote: > > On Sat, 29 Sep 2007 02:32:44 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > > > On Friday 28 September 2007, Frans Pop wrote: > > > > My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot after: > > > > Marking TSC unstable due to: possible TSC halt in C2. > > > > Time: acpi_pm clocksource has been installed. > > > > > > A few new boot attempts show the problem is more likely at: > > > Probing IDE interface ide0... > > Looks like it is both: hpet killing IDE? > > > Two iterations should get you into the culprit zone. > > Thanks for the pointers. Luckily I ended up in a quite narrow zone between > two of the points you indicated (10 iterations). > > And the winner is: > > 3fe6c0016fd863b233097a8219a0d8577c2fd503 is first bad commit > commit 3fe6c0016fd863b233097a8219a0d8577c2fd503 > Author: Udo A. Steinberg <...> > hpet-force-enable-on-ich34 > > Guess the comments about thin ice and testing were justified :-) > > lspci and a 2.6.23-rc6 dmesg for this system can be found in: > http://lkml.org/lkml/2007/9/19/300 Great, thanks for doing that. I guess I'll drop the patch for now in that case. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2
On Sat, Sep 29, 2007 at 05:37:29PM +0800, Dave Young wrote: > 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() > [] dump_trace+0x1bf/0x1d0 > [] show_trace_log_lvl+0x18/0x30 > [] show_trace+0xf/0x20 > [] dump_stack+0x12/0x20 > [] sysfs_add_one+0xa0/0xe0 > [] create_dir+0x48/0xb0 > [] sysfs_create_dir+0x29/0x50 > [] create_dir+0x1b/0x50 > [] kobject_add+0x46/0x150 > [] kernel_param_sysfs_setup+0x50/0xb0 > [] param_sysfs_builtin+0xee/0x130 > [] param_sysfs_init+0x24/0x60 > [] do_initcalls+0x46/0x1e0 > [] kernel_init+0x62/0xb0 > [] 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. That is very wierd, do you have both USB built in and as a module somehow? > [] dump_trace+0x1bf/0x1d0 > [] show_trace_log_lvl+0x18/0x30 > [] show_trace+0xf/0x20 > [] dump_stack+0x12/0x20 > [] kobject_add+0xf6/0x150 > [] kernel_param_sysfs_setup+0x50/0xb0 > [] param_sysfs_builtin+0xee/0x130 > [] param_sysfs_init+0x24/0x60 > [] do_initcalls+0x46/0x1e0 > [] kernel_init+0x62/0xb0 > [] kernel_thread_helper+0x7/0x14 > === > Module 'usbcore' failed to be added to sysfs, error number -17 I think I need to clean up the double stack trace here, that's reall not needed :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
Ilpo Järvinen wrote: > On Fri, 28 Sep 2007, Ilpo Järvinen wrote: >> On Fri, 28 Sep 2007, Cedric Le Goater wrote: >> >>> I just found that warning in my logs. It seems that it's been >>> happening since rc7-mm1 at least. >>> >>> WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 >>> tcp_fastretrans_alert() >>> >>> Call Trace: >>>[] tcp_ack+0xcd6/0x1894 >>> ...snip... >> ...Thanks for the report, I'll have look what could still break >> fackets_out... > > I think this one is now clear to me, tcp_fragment/collapse adjusts > fackets_out (incorrectly) also for reno flow when there were some dupACKs > that made sacked_out != 0. Could you please try if patch below proves all > them to be of non-SACK origin... In case that's true, it's rather > harmless, I'll send a fix on Monday or so (this would anyway be needed)... > If you find out that them occur with SACK enabled flow, that would be > more interesting and requires more digging... 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
> On Fri, 28 Sep 2007, Cedric Le Goater wrote:
>
> > I just found that warning in my logs. It seems that it's been
> > happening since rc7-mm1 at least.
> >
> > WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
> > tcp_fastretrans_alert()
> >
> > Call Trace:
> >[] tcp_ack+0xcd6/0x1894
> > ...snip...
>
> ...Thanks for the report, I'll have look what could still break
> fackets_out...
I think this one is now clear to me, tcp_fragment/collapse adjusts
fackets_out (incorrectly) also for reno flow when there were some dupACKs
that made sacked_out != 0. Could you please try if patch below proves all
them to be of non-SACK origin... In case that's true, it's rather
harmless, I'll send a fix on Monday or so (this would anyway be needed)...
If you find out that them occur with SACK enabled flow, that would be
more interesting and requires more digging...
--
i.
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 2286361..e642779 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2311,8 +2311,10 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
int flag)
if (!tp->packets_out)
tp->sacked_out = 0;
- if (WARN_ON(!tp->sacked_out && tp->fackets_out))
+ if (WARN_ON(!tp->sacked_out && tp->fackets_out)) {
+ printk(KERN_ERR "TCP %d\n", tcp_is_reno(tp));
tp->fackets_out = 0;
+ }
/* Now state machine starts.
* A. ECE, hence prohibit cwnd undoing, the reduction is required. */
Re: 2.6.23-rc8-mm2
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() [] dump_trace+0x1bf/0x1d0 [] show_trace_log_lvl+0x18/0x30 [] show_trace+0xf/0x20 [] dump_stack+0x12/0x20 [] sysfs_add_one+0xa0/0xe0 [] create_dir+0x48/0xb0 [] sysfs_create_dir+0x29/0x50 [] create_dir+0x1b/0x50 [] kobject_add+0x46/0x150 [] kernel_param_sysfs_setup+0x50/0xb0 [] param_sysfs_builtin+0xee/0x130 [] param_sysfs_init+0x24/0x60 [] do_initcalls+0x46/0x1e0 [] kernel_init+0x62/0xb0 [] 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. [] dump_trace+0x1bf/0x1d0 [] show_trace_log_lvl+0x18/0x30 [] show_trace+0xf/0x20 [] dump_stack+0x12/0x20 [] kobject_add+0xf6/0x150 [] kernel_param_sysfs_setup+0x50/0xb0 [] param_sysfs_builtin+0xee/0x130 [] param_sysfs_init+0x24/0x60 [] do_initcalls+0x46/0x1e0 [] kernel_init+0x62/0xb0 [] 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 :00:1d.7[A] -> GSI 21 (level, low) -> IRQ 18 PCI: Setting latency timer of device :00:1d.7 to 64 ehci_hcd :00:1d.7: EHCI Host Controller ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 1 ehci_hcd :00:1d.7: debug port 1 PCI: cache line size of 128 is not supported by device :00:1d.7 ehci_hcd :00:1d.7: irq 18, io mem 0xffa80800 ehci_hcd :00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected usb usb1: new device found, idVendor=, idProduct= usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 2.6.23-rc8-mm2 ehci_hcd usb usb1: SerialNumber: :00:1d.7 ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver USB Universal Host Controller Interface driver v3.0 ACPI: PCI Interrupt :00:1d.0[A] -> GSI 21 (level, low) -> IRQ 18 PCI: Setting latency timer of device :00:1d.0 to 64 uhci_hcd :00:1d.0: UHCI Host Controller uhci_hcd :00:1d.0: new USB bus registered, assigned bus number 2 uhci_hcd :00:1d.0: irq 18, io base 0xff80 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected usb usb2: new device found, idVendor=, idProduct= usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: UHCI Host Controller usb usb2: Manufacturer: Linux 2.6.23-rc8-mm2 uhci_hcd usb usb2: SerialNumber: :00:1d.0 ACPI: PCI Interrupt :00:1d.1[B] -> GSI 22 (level, low) -> IRQ 19 PCI: Setting latency timer of device :00:1d.1 to 64 uhci_hcd :00:1d.1: UHCI Host Controller uhci_hcd :00:1d.1: new USB bus registered, assigned bus number 3 uhci_hcd :00:1d.1: irq 19, io base 0xff60 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected usb usb3: new device found, idVendor=, idProduct= usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: UHCI Host Controller usb usb3: Manufacturer: Linux 2.6.23-rc8-mm2 uhci_hcd usb usb3: SerialNumber: :00:1d.1 ACPI: PCI Interrupt :00:1d.2[C] -> GSI 18 (level, low) -> IRQ 20 PCI: Setting latency timer of device :00:1d.2 to 64 uhci_hcd :00:1d.2: UHCI Host Controller uhci_hcd :00:1d.2: new USB bus registered, assigned bus number 4 uhci_hcd :00:1d.2: irq 20, io base 0xff40 usb usb4: configuration #1 chosen from 1 choice hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected usb 1-1: new high speed USB device using ehci_hcd and address 2 usb usb4: new device found, idVendor=, idProduct= usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: UHCI Host Controller usb usb4: Manufacturer: Linux 2.6.23-rc8-mm2 uhci_hcd usb usb4: SerialNumber: :00:1d.2 ACPI: PCI Interrupt :00:1d.3[D] -> GSI 23 (level, low) -> IRQ 21 PCI: Setting latency timer of device :00:1d.3 to 64 uhci_hcd :00:1d.3: UHCI Host Controller uhci_hcd :00:1d.3: new USB bus registered, assigned bus number 5 uhci_hcd :00:1d.3: irq 21, io base 0xff20 usb usb5: configuration #1 chosen from 1 choice hub 5-0:1.0: USB hub found hub 5-0:1.0: 2 ports detected usb 1-1: configuration #1 chosen from 1 choice hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb usb5: new device found, idVendor=, idProduct= usb usb5: new device strings: Mfr=
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Sat, 29 Sep 2007 02:32:44 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > On Friday 28 September 2007, Frans Pop wrote: > > My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot after: > > Marking TSC unstable due to: possible TSC halt in C2. > > Time: acpi_pm clocksource has been installed. > > A few new boot attempts show the problem is more likely at: > Probing IDE interface ide0... > > > It may not actually hang, but rather end up in a loop as after some time > > the fan goes wild. > > Unfortunately I have no serial port and this seems too early for netconsole, > so cannot catch a boot log. > > > Any suggestions where to look before I do a bisect? Not really, sorry. I usually start at mm.patch when I don't have a clue. It mm.patch fails then pop off all the x86 patches (down to git-ipwireless_cs.patch). If mm.patch doesn't fail then push on all the memory management patches (up to mm-test-and-set-zone-reclaim-lock-before-starting-cleanup.patch). Two iterations should get you into the culprit zone. But please do bisect it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Friday 28 September 2007, Frans Pop wrote: > My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot after: > Marking TSC unstable due to: possible TSC halt in C2. > Time: acpi_pm clocksource has been installed. A few new boot attempts show the problem is more likely at: Probing IDE interface ide0... > It may not actually hang, but rather end up in a loop as after some time > the fan goes wild. Unfortunately I have no serial port and this seems too early for netconsole, so cannot catch a boot log. > Any suggestions where to look before I do a bisect? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftruncate
Dave Hansen wrote: On Fri, 2007-09-28 at 01:30 -0700, Andrew Morton wrote: On Thu, 27 Sep 2007 15:54:20 -0600 Zan Lynx <[EMAIL PROTECTED]> wrote: Near the end of my boot sequence, there is a kernel error. I am not sure exactly what user-space is doing to make this happen, but I know that a simple shell and some filesystem operations do not cause it. This error also occurred in 2.6.23-rc8-mm1 but I didn't have time to post it and hoped it would just go away. I never tested 2.6.23-rc7-mm*, and the error did not happen in rc6-mm1. console [netcon0] enabled netconsole: network logging started eth0: no IPv6 routers present Unable to handle kernel NULL pointer dereference at 0053 RIP: [] __mnt_is_readonly+0x0/0x20 PGD 0 Oops: [1] SMP last sysfs file: /block/sr0/size CPU 0 Modules linked in: netconsole configfs sg ipv6 evdev usbhid hid usb_storage libusual psmouse serio_raw ssb video output ehci_hcd ohci_hcd usbcore snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc Pid: 7291, comm: smbd Not tainted 2.6.23-rc8-mm2 #1 RIP: 0010:[] [] __mnt_is_readonly+0x0/0x20 RSP: 0018:8100068b1b60 EFLAGS: 00010296 RAX: 810007108000 RBX: 81000261d8c0 RCX: 8093aca0 RDX: 0004 RSI: 8092e950 RDI: 0003 RBP: 0003 R08: 0003 R09: 8061f7cd R10: b256aacb R11: R12: ffe2 R13: 8100068b1bd8 R14: 8100068b1ee8 R15: 81000655a910 FS: 7f6f0930c6f0() GS:806ce000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0053 CR3: 07cb2000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process smbd (pid: 7291, threadinfo 8100068b, task 810007108000) last branch before last exception/interrupt from [] mnt_want_write+0x3a/0x90 to [] __mnt_is_readonly+0x0/0x20 Stack: 802cc37f 8100078cd9a0 8100068b1bd8 8100078cd9a0 802c82bc 8100078cd780 8100078cd9a0 8100068b1bd8 8100068b1ee8 3000 Call Trace: [] mnt_want_write+0x3f/0x90 [] file_update_time+0x2c/0xe0 [] truncate_file_body+0x148/0x3f0 [] __lock_acquire+0x583/0x1180 [] _spin_unlock+0x17/0x20 [] store_black_box+0x82/0x90 [] safe_link_add+0x75/0xd0 [] setattr_unix_file+0x207/0x220 [] _spin_unlock_irq+0x24/0x30 [] __down_write_nested+0xa1/0xc0 [] notify_change+0xf7/0x2c0 [] do_truncate+0x5e/0x80 [] sys_ftruncate+0x119/0x130 [] system_call+0x7e/0x83 But you oopsed in a different place, via resier4. I don't know if Dave considers that part of his mandate - he could reasonably ask the reiser4 guys to help fix things up. First of all, thanks a bunch for the report. It really helps. This could probably be considered a reiser4 bug, excited by the r/o bind mount changes. See how that pointer is 0x...053? That's a weird offset for a structure that should be mostly word-aligned. I think that's because reiser4 stack-allocates a 'struct file', and then only initializes parts of it, *not* including the vfsmount. The test in file_update_time() is for f->f_vfsmnt == NULL, and I think we had something like 0x1 in there. I think that stack allocation is a pretty nasty trick for a structure that's supposed to be pretty persistent and dynamically allocated, and is certainly something that needs to get fixed up in a proper way. agreed. This works around the problem for now, but this could potentially cause more bugs any time we add some member to 'struct file' and depend on its state being sane anywhere in the VFS. If there's a list anywhere of merge-stopper reiser4 bugs around, this should probably go in there. will be fixed. In general, I think reiser4 also lets the 'struct file' get way too deep into its internals. For instance, I would expect reiser4_write_extent() to take a plain inode, not a 'struct file'. This uses struct file's private data for so-called hints (speedup technique). Why not plain inode? I think because this is remains of removed file-as-directory stuff. Signed-off-by: Dave Hansen <[EMAIL PROTECTED]> --- lxc-dave/fs/reiser4/plugin/file/file.c |1 + 1 file changed, 1 insertion(+) diff -puN fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt fs/reiser4/plugin/file/file.c --- lxc/fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt 2007-09-28 09:10:51.0 -0700 +++ lxc-dave/fs/reiser4/plugin/file/file.c 2007-09-28 09:11:20.0 -0700 @@ -581,6 +581,7 @@ static int truncate_file_body(struct ino file.private_data = NULL; file.f_pos = new_size; file.private_data = NULL; + file.f_vfsmnt = NULL; uf_info = unix_file_inode_data(inode); result = find_fil
Re: 2.6.23-rc8-mm2: problems on HP nx6325
On Thursday, 27 September 2007 17:49, Thomas Gleixner wrote: > On Thu, 2007-09-27 at 17:59 +0200, Rafael J. Wysocki wrote: > > > 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) > > > > This one is fixed by the following patch: > > > > --- > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > 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 <[EMAIL PROTECTED]> > > 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, Rafael > > --- > > 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; > > > -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
On Fri, 28 Sep 2007, Cedric Le Goater wrote: > Hello ! > > Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ > > 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: >[] tcp_ack+0xcd6/0x1894 > ...snip... ...Thanks for the report, I'll have look what could still break fackets_out... -- i. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftruncate
On Fri, 2007-09-28 at 01:30 -0700, Andrew Morton wrote: > On Thu, 27 Sep 2007 15:54:20 -0600 Zan Lynx <[EMAIL PROTECTED]> wrote: > > Near the end of my boot sequence, there is a kernel error. I am not > > sure exactly what user-space is doing to make this happen, but I know > > that a simple shell and some filesystem operations do not cause it. > > > > This error also occurred in 2.6.23-rc8-mm1 but I didn't have time to > > post it and hoped it would just go away. I never tested 2.6.23-rc7-mm*, > > and the error did not happen in rc6-mm1. > > > > console [netcon0] enabled > > netconsole: network logging started > > eth0: no IPv6 routers present > > Unable to handle kernel NULL pointer dereference at 0053 RIP: > > [] __mnt_is_readonly+0x0/0x20 > > PGD 0 > > Oops: [1] SMP > > last sysfs file: /block/sr0/size > > CPU 0 > > Modules linked in: netconsole configfs sg ipv6 evdev usbhid hid usb_storage > > libusual psmouse serio_raw ssb video output ehci_hcd ohci_hcd usbcore > > snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc > > Pid: 7291, comm: smbd Not tainted 2.6.23-rc8-mm2 #1 > > RIP: 0010:[] [] > > __mnt_is_readonly+0x0/0x20 > > RSP: 0018:8100068b1b60 EFLAGS: 00010296 > > RAX: 810007108000 RBX: 81000261d8c0 RCX: 8093aca0 > > RDX: 0004 RSI: 8092e950 RDI: 0003 > > RBP: 0003 R08: 0003 R09: 8061f7cd > > R10: b256aacb R11: R12: ffe2 > > R13: 8100068b1bd8 R14: 8100068b1ee8 R15: 81000655a910 > > FS: 7f6f0930c6f0() GS:806ce000() knlGS: > > CS: 0010 DS: ES: CR0: 8005003b > > CR2: 0053 CR3: 07cb2000 CR4: 06e0 > > DR0: DR1: DR2: > > DR3: DR6: 0ff0 DR7: 0400 > > Process smbd (pid: 7291, threadinfo 8100068b, task 810007108000) > > last branch before last exception/interrupt > > from [] mnt_want_write+0x3a/0x90 > > to [] __mnt_is_readonly+0x0/0x20 > > Stack: 802cc37f 8100078cd9a0 8100068b1bd8 8100078cd9a0 > > 802c82bc 8100078cd780 8100078cd9a0 > > 8100068b1bd8 8100068b1ee8 3000 > > Call Trace: > > [] mnt_want_write+0x3f/0x90 > > [] file_update_time+0x2c/0xe0 > > [] truncate_file_body+0x148/0x3f0 > > [] __lock_acquire+0x583/0x1180 > > [] _spin_unlock+0x17/0x20 > > [] store_black_box+0x82/0x90 > > [] safe_link_add+0x75/0xd0 > > [] setattr_unix_file+0x207/0x220 > > [] _spin_unlock_irq+0x24/0x30 > > [] __down_write_nested+0xa1/0xc0 > > [] notify_change+0xf7/0x2c0 > > [] do_truncate+0x5e/0x80 > > [] sys_ftruncate+0x119/0x130 > > [] system_call+0x7e/0x83 > > But you oopsed in a different place, via resier4. I don't know if Dave > considers that part of his mandate - he could reasonably ask the reiser4 > guys to help fix things up. First of all, thanks a bunch for the report. It really helps. This could probably be considered a reiser4 bug, excited by the r/o bind mount changes. See how that pointer is 0x...053? That's a weird offset for a structure that should be mostly word-aligned. I think that's because reiser4 stack-allocates a 'struct file', and then only initializes parts of it, *not* including the vfsmount. The test in file_update_time() is for f->f_vfsmnt == NULL, and I think we had something like 0x1 in there. I think that stack allocation is a pretty nasty trick for a structure that's supposed to be pretty persistent and dynamically allocated, and is certainly something that needs to get fixed up in a proper way. This works around the problem for now, but this could potentially cause more bugs any time we add some member to 'struct file' and depend on its state being sane anywhere in the VFS. If there's a list anywhere of merge-stopper reiser4 bugs around, this should probably go in there. In general, I think reiser4 also lets the 'struct file' get way too deep into its internals. For instance, I would expect reiser4_write_extent() to take a plain inode, not a 'struct file'. Signed-off-by: Dave Hansen <[EMAIL PROTECTED]> --- lxc-dave/fs/reiser4/plugin/file/file.c |1 + 1 file changed, 1 insertion(+) diff -puN fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt fs/reiser4/plugin/file/file.c --- lxc/fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt 2007-09-28 09:10:51.0 -0700 +++ lxc-dave/fs/reiser4/plugin/file/file.c 2007-09-28 09:11:20.0 -0700 @@ -581,6 +581,7 @@ static int truncate_file_body(struct ino file.private_data = NULL; file.f_pos = new_size; file.private_data = NULL; + file.f_vfsmnt = NULL; uf_info = unix_file_inode_data(inode); result = find_fil
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
Hello ! Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ 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: [] tcp_ack+0xcd6/0x1894 [] tcp_data_queue+0x5be/0xae7 [] tcp_rcv_established+0x61f/0x6df [] __lock_acquire+0x8a1/0xf1b [] tcp_v4_do_rcv+0x3e/0x394 [] tcp_v4_rcv+0x61c/0x9a9 [] ip_local_deliver+0x1da/0x2a4 [] ip_rcv+0x583/0x5c9 [] packet_rcv_spkt+0x19a/0x1a8 [] netif_receive_skb+0x2cf/0x2f5 [] :tg3:tg3_poll+0x65d/0x8a4 [] net_rx_action+0xb8/0x191 [] __do_softirq+0x5f/0xe0 [] call_softirq+0x1c/0x28 [] do_softirq+0x3b/0xb8 [] irq_exit+0x4e/0x50 [] do_IRQ+0xbd/0xd7 [] mwait_idle+0x0/0x4d [] ret_from_intr+0x0/0xf [] mwait_idle+0x43/0x4d [] enter_idle+0x22/0x24 [] cpu_idle+0x9d/0xc0 [] rest_init+0x55/0x57 [] start_kernel+0x2d6/0x2e2 [] _sinittext+0x134/0x13b - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftruncate
On Thu, 27 Sep 2007 15:54:20 -0600 Zan Lynx <[EMAIL PROTECTED]> wrote: > Kernel 2.6.23-rc8-mm2 on a AMD-64, filesystems mounted are reiserfs, > reiser4 and tmpfs. > netconsole dmesg output and .config are included below. reiser3 has a known problem, but it oopses in a different place and a fix is in the works. > Near the end of my boot sequence, there is a kernel error. I am not > sure exactly what user-space is doing to make this happen, but I know > that a simple shell and some filesystem operations do not cause it. > > This error also occurred in 2.6.23-rc8-mm1 but I didn't have time to > post it and hoped it would just go away. I never tested 2.6.23-rc7-mm*, > and the error did not happen in rc6-mm1. > > console [netcon0] enabled > netconsole: network logging started > eth0: no IPv6 routers present > Unable to handle kernel NULL pointer dereference at 0053 RIP: > [] __mnt_is_readonly+0x0/0x20 > PGD 0 > Oops: [1] SMP > last sysfs file: /block/sr0/size > CPU 0 > Modules linked in: netconsole configfs sg ipv6 evdev usbhid hid usb_storage > libusual psmouse serio_raw ssb video output ehci_hcd ohci_hcd usbcore > snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc > Pid: 7291, comm: smbd Not tainted 2.6.23-rc8-mm2 #1 > RIP: 0010:[] [] > __mnt_is_readonly+0x0/0x20 > RSP: 0018:8100068b1b60 EFLAGS: 00010296 > RAX: 810007108000 RBX: 81000261d8c0 RCX: 8093aca0 > RDX: 0004 RSI: 8092e950 RDI: 0003 > RBP: 0003 R08: 0003 R09: 8061f7cd > R10: b256aacb R11: R12: ffe2 > R13: 8100068b1bd8 R14: 8100068b1ee8 R15: 81000655a910 > FS: 7f6f0930c6f0() GS:806ce000() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 0053 CR3: 07cb2000 CR4: 06e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process smbd (pid: 7291, threadinfo 8100068b, task 810007108000) > last branch before last exception/interrupt > from [] mnt_want_write+0x3a/0x90 > to [] __mnt_is_readonly+0x0/0x20 > Stack: 802cc37f 8100078cd9a0 8100068b1bd8 8100078cd9a0 > 802c82bc 8100078cd780 8100078cd9a0 > 8100068b1bd8 8100068b1ee8 3000 > Call Trace: > [] mnt_want_write+0x3f/0x90 > [] file_update_time+0x2c/0xe0 > [] truncate_file_body+0x148/0x3f0 > [] __lock_acquire+0x583/0x1180 > [] _spin_unlock+0x17/0x20 > [] store_black_box+0x82/0x90 > [] safe_link_add+0x75/0xd0 > [] setattr_unix_file+0x207/0x220 > [] _spin_unlock_irq+0x24/0x30 > [] __down_write_nested+0xa1/0xc0 > [] notify_change+0xf7/0x2c0 > [] do_truncate+0x5e/0x80 > [] sys_ftruncate+0x119/0x130 > [] system_call+0x7e/0x83 But you oopsed in a different place, via resier4. I don't know if Dave considers that part of his mandate - he could reasonably ask the reiser4 guys to help fix things up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: BUG near reiserfs_xattr_set
On Thu, Sep 27, 2007 at 12:48:33PM -0700, Andrew Morton wrote: > > __fput+0x124/0x1a9 > > fput+0x31/0x35 > > reiserfs_xattr_set+0x291/0x2b0 [reiserfs] > > user_set+0x4c/0x57 [reiserfs] > > reiserfs_setxattr+0x81/0xf1 [reiserfs] > > vfs_setxattr+0x7d/0xfa > > setxattr+0xb9/0xd1 > > sys_lsetxattr+0x4c/0x85 > > sysenter_past_esp+0x57/0x85 > > > > EIP: mnt_drop_write+0x5b/0x9d > > > > Hi, 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: BUG near reiserfs_xattr_set
On Thu, 2007-09-27 at 12:48 -0700, Andrew Morton wrote: > > Hi, Dave! > > > It's fully reproducible. > > > > /home is mounted with the following options: > >/dev/mapper/vglinux1-lvhome on /home type reiserfs > (rw,noatime,nodiratime,user_xattr) > > > > This BUG happened with rc8-mm1 too. > > rc6-mm1 works fine. > > I didn't try rc7-mm1. Got it. I'll try to reproduce. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: BUG near reiserfs_xattr_set
On Thu, 27 Sep 2007 21:18:55 +0200 Laurent Riffard <[EMAIL PROTECTED]> wrote: > Le 27.09.2007 11:22, Andrew Morton a écrit : > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ > > I've got this BUG a few seconds after I logged in into Gnome desktop : > > [partially hand copied BUG] > BUG: unable to handle kernel NULL pointer dereference at virtual address > > printing eip: c016f55e *pde=0b8a5067 *pte= > Oops: 0002 [#1] PREEMPT > ... > Process beagled... > ... > Call Trace: > __fput+0x124/0x1a9 > fput+0x31/0x35 > reiserfs_xattr_set+0x291/0x2b0 [reiserfs] > user_set+0x4c/0x57 [reiserfs] > reiserfs_setxattr+0x81/0xf1 [reiserfs] > vfs_setxattr+0x7d/0xfa > setxattr+0xb9/0xd1 > sys_lsetxattr+0x4c/0x85 > sysenter_past_esp+0x57/0x85 > > EIP: mnt_drop_write+0x5b/0x9d > Hi, Dave! > It's fully reproducible. > > /home is mounted with the following options: >/dev/mapper/vglinux1-lvhome on /home type reiserfs > (rw,noatime,nodiratime,user_xattr) > > This BUG happened with rc8-mm1 too. > rc6-mm1 works fine. > I didn't try rc7-mm1. > > .config attached. > ~~ > laurent > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: problems on HP nx6325
On Thursday, 27 September 2007 21:37, Randy Dunlap wrote: > On Thu, 27 Sep 2007 21:48:59 +0200 Rafael J. Wysocki wrote: > > > On Thursday, 27 September 2007 21:19, Sam Ravnborg wrote: > > > On Thu, Sep 27, 2007 at 10:33:51AM -0700, Randy Dunlap wrote: > > > > On Thu, 27 Sep 2007 18:53:46 +0200 Sam Ravnborg wrote: > > > > > > > > > Hi Rafael. > > > > > > > > > > > > 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 <[EMAIL PROTECTED]> > > > > > > --- > > > > > > 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; > > > > > > > > > > > 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?? > > > > > > > > I did: > > > > But I didn't. I'm not sure why. > > I did only on one build machine (multiple times). I tried > to reproduce it on another machine and could not. I blame > different build tools. That's possible. I use the default openSUSE 10.2 toolchain. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: problems on HP nx6325
On Thu, 27 Sep 2007 21:48:59 +0200 Rafael J. Wysocki wrote: > On Thursday, 27 September 2007 21:19, Sam Ravnborg wrote: > > On Thu, Sep 27, 2007 at 10:33:51AM -0700, Randy Dunlap wrote: > > > On Thu, 27 Sep 2007 18:53:46 +0200 Sam Ravnborg wrote: > > > > > > > Hi Rafael. > > > > > > > > > > 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 <[EMAIL PROTECTED]> > > > > > --- > > > > > 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; > > > > > > > > > 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?? > > > > > > I did: > > But I didn't. I'm not sure why. I did only on one build machine (multiple times). I tried to reproduce it on another machine and could not. I blame different build tools. > > > WARNING: vmlinux.o(.text+0x7778): Section mismatch: reference to > > > .init.data:disable_apic_timer (between 'identify_cpu' and > > > 'IRQ0x20_interrupt') > > > > 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. > > Yes. --- ~Randy Phaedrus says that Quality is about caring. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: problems on HP nx6325
On Thursday, 27 September 2007 21:19, Sam Ravnborg wrote: > On Thu, Sep 27, 2007 at 10:33:51AM -0700, Randy Dunlap wrote: > > On Thu, 27 Sep 2007 18:53:46 +0200 Sam Ravnborg wrote: > > > > > Hi Rafael. > > > > > > > > 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 <[EMAIL PROTECTED]> > > > > --- > > > > 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; > > > > > > > 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?? > > > > I did: But I didn't. I'm not sure why. > > WARNING: vmlinux.o(.text+0x7778): Section mismatch: reference to > > .init.data:disable_apic_timer (between 'identify_cpu' and > > 'IRQ0x20_interrupt') > > 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. Yes. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: BUG near reiserfs_xattr_set
Le 27.09.2007 11:22, Andrew Morton a écrit : > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ I've got this BUG a few seconds after I logged in into Gnome desktop : [partially hand copied BUG] BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: c016f55e *pde=0b8a5067 *pte= Oops: 0002 [#1] PREEMPT ... Process beagled... ... Call Trace: __fput+0x124/0x1a9 fput+0x31/0x35 reiserfs_xattr_set+0x291/0x2b0 [reiserfs] user_set+0x4c/0x57 [reiserfs] reiserfs_setxattr+0x81/0xf1 [reiserfs] vfs_setxattr+0x7d/0xfa setxattr+0xb9/0xd1 sys_lsetxattr+0x4c/0x85 sysenter_past_esp+0x57/0x85 EIP: mnt_drop_write+0x5b/0x9d It's fully reproducible. /home is mounted with the following options: /dev/mapper/vglinux1-lvhome on /home type reiserfs (rw,noatime,nodiratime,user_xattr) This BUG happened with rc8-mm1 too. rc6-mm1 works fine. I didn't try rc7-mm1. .config attached. ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Thu Sep 27 18:18:14 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_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 is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # 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=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # 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 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MCORE2 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINI
Re: 2.6.23-rc8-mm2: problems on HP nx6325
On Thu, Sep 27, 2007 at 10:33:51AM -0700, Randy Dunlap wrote: > On Thu, 27 Sep 2007 18:53:46 +0200 Sam Ravnborg wrote: > > > Hi Rafael. > > > > > > 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 <[EMAIL PROTECTED]> > > > --- > > > 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; > > > > > 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?? > > I did: > > WARNING: vmlinux.o(.text+0x7778): Section mismatch: reference to > .init.data:disable_apic_timer (between 'identify_cpu' and 'IRQ0x20_interrupt') 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: problems on HP nx6325
On Thu, 27 Sep 2007 18:53:46 +0200 Sam Ravnborg wrote: > Hi Rafael. > > > > 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 <[EMAIL PROTECTED]> > > --- > > 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; > > > 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?? 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: problems on HP nx6325
Hi Rafael. > > 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 <[EMAIL PROTECTED]> > --- > 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; > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: problems on HP nx6325
On Thu, 2007-09-27 at 17:59 +0200, Rafael J. Wysocki wrote: > > 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) > > This one is fixed by the following patch: > > --- > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > 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 <[EMAIL PROTECTED]> Doh, I knew I blew it. Good catch, thanks, tglx > --- > 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; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: problems on HP nx6325
On Thursday, 27 September 2007 17:19, Rafael J. Wysocki wrote: > On Thursday, 27 September 2007 11:22, Andrew Morton wrote: > > > > 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. > > 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) This one is fixed by the following patch: --- From: Rafael J. Wysocki <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> --- 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; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: problems on HP nx6325
On Thursday, 27 September 2007 11:22, Andrew Morton wrote: > > 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. 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=, idProduct= 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: :00:13.1 [] proc_register+0x15b/0x173 [] create_proc_entry+0x74/0x89 [] :rtc_core:rtc_proc_add_device+0x25/0x48 [] :rtc_core:rtc_device_register+0x182/0x215 [] sysfs_add_one+0xbf/0xc9 [] :rtc_cmos:cmos_do_probe+0xa5/0x220 [] :rtc_cmos:cmos_pnp_probe+0x41/0x43 [] pnp_device_probe+0x7b/0xa2 [] driver_probe_device+0x100/0x18f [] __driver_attach+0x70/0xae [] __driver_attach+0x0/0xae [] bus_for_each_dev+0x49/0x7a [] driver_attach+0x1c/0x1e [] bus_add_driver+0x86/0x1d6 [] driver_register+0x72/0x76 [] pnp_register_driver+0x1c/0x1e [] :rtc_cmos:cmos_init+0x10/0x12 [] sys_init_module+0x16df/0x1864 [] :rtc_core:rtc_device_register+0x0/0x215 [] 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 appear, but the networking works nevertheless: Call Trace: [] sysfs_add_one+0x5c/0xc9 [] sysfs_create_link+0xd1/0x12c [] device_rename+0x17a/0x1db [] dev_change_name+0x13c/0x233 [] dev_ifsioc+0x337/0x403 [] dev_ioctl+0x3b4/0x4cc [] handle_mm_fault+0x1fe/0x6f3 [] __up_read+0x8f/0x97 [] sock_ioctl+0x1fe/0x20c [] do_ioctl+0x2a/0x77 [] vfs_ioctl+0x251/0x26e [] sys_ioctl+0x57/0x7b [] system_call+0x7e/0x83 net ethxx0: device_rename: sysfs_create_symlink failed (-17) [--snip--] WARNING: at /home/rafael/src/mm/linux-2.6.23-rc8-mm2/fs/sysfs/dir.c:433 sysfs_ad d_one() Call Trace: [] sysfs_add_one+0x5c/0xc9 [] sysfs_create_link+0xd1/0x12c ohci_hcd :00:13.1: GetStatus roothub.portstatus [0] = 0x00100103 PRSC PPS PE S CCS [] device_rename+0x17a/0x1db [] dev_change_name+0x13c/0x233 [] dev_ifsioc+0x337/0x403 usb 3-1: new full speed USB device using ohci_hcd and address 2 [] dev_ioctl+0x3b4/0x4cc [] handle_mm_fault+0x1fe/0x6f3 [] __up_read+0x8f/0x97 [] sock_ioctl+0x1fe/0x20c ohci_hcd :00:13.1: GetStatus roothub.portstatus [0] = 0x00100103 PRSC PPS PE S CCS [] do_ioctl+0x2a/0x77 [] vfs_ioctl+0x251/0x26e [] sys_ioctl+0x57/0x7b [] system_call+0x7e/0x83 usb 3-1: ep0 maxpacket = 8 usb 3-1: default language 0x0409 net ethxx1: device_rename: sysfs_create_symlink failed (-17) [--snip--] ethxx0 renamed to eth1 sysfs: duplicate filename 'eth1' can not be created WARNING: at /home/rafael/src/mm/linux-2.6.23-rc8-mm2/fs/sysfs/dir.c:433 sysfs_ad d_one() Call Trace: [] sysfs_add_one+0x5c/0xc9 [] sysfs_create_link+0xd1/0x12c [] device_rename+0x17a/0x1db [] dev_change_name+0x13c/0x233 [] dev_ifsioc+0x337/0x403 [] dev_ioctl+0x3b4/0x4cc [] handle_mm_fault+0x1fe/0x6f3 [] __up_read+0x8f/0x97 [] sock_ioctl+0x1fe/0x20c [] do_ioctl+0x2a/0x77 [] vfs_ioctl+0x251/0x26e [] sys_ioctl+0x57/0x7b [] system_call+0x7e/0x83 net eth1: device_rename: sysfs_create_symlink failed (-17) ethxx1 renamed to eth0 hub 3-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x301 Bluetooth: Core ver 2.11 sysfs: duplicate filename 'eth0' can not be created WARNING: at /home/rafael/src/mm/linux-2.6.23-rc8-mm2/fs/sysfs/dir.c:433 sysfs_ad d_one() Call Trace: [] sysfs_add_one+0x5c/0xc9 [] sysfs_create_link+0xd1/0x12c [] device_rename+0x17a/0x1db [] dev_change_name+0x13c/0x233 [] dev_ifsioc+0x337/0x403 [] dev_ioctl+0x3b4/0x4cc [] handle_mm_fault+0x1fe/0x6f3 [] __up_read+0x8f/0x97 [] sock_ioctl+0x1fe/0x20c [] do_ioctl+0x2a/0x77 [] vfs_ioctl+0x251/0x26e [] sys_ioctl+0x57/0x7b [] system_call+0x7e/0x83 net eth0: device_rename: sysfs_create_symlink failed (-17) Full dmesg attached. Greetings, Rafael Linux version 2.6.23-rc8-mm2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #23 SMP Thu Sep 27 14:51:09 CEST 2007 Command line: root=/dev/sda3 vga=792 resume=/dev/sda1 no_console_suspend BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820:
Re: 2.6.23-rc8-mm2 - drivers/net/ibm_newemac/mal - broken
Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
