All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Pavel Machek <pavel@suse.cz>
Cc: kernel list <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	macro@ds2.pg.gda.pl
Subject: Re: Unify common parts of i8259.c
Date: Tue, 20 May 2008 22:47:50 +0200	[thread overview]
Message-ID: <20080520204750.GA31409@elte.hu> (raw)
In-Reply-To: <20080520151528.GA1596@elf.ucw.cz>


* Pavel Machek <pavel@suse.cz> wrote:

> Merge common parts of i8259_{32,64} into i8259.c.

hm, did you intend this to be a 'mechanic' (i.e. no functionality 
changes expected) unification?

i stuck it into -tip for testing and it caused a boot failure after a 
couple of bootups, with this config:

  http://redhat.com/~mingo/misc/config-Tue_May_20_22_15_40_CEST_2008.bad

the hang is during early bootup, after SLUB init:

  SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
  [ hard hang ]

full bootlog below. Reverting your patch fixes the bootup. The next line 
would be:

  Calibrating delay using timer specific routine.. 4023.05 BogoMIPS (lpj=8046112)

so somewhere between that and the SLUB init is it hanging.

If this change is intentionally not mechanic then please split this into 
the mechanic and non-mechanic portions, to make it all bisectable. If 
it's supposed to be mechanic then there's a bug in it - in that case a 
more gradual conversion is useful too.

We'd prefer to have 10 or 20 small commits instead one large commit - 
because in -tip we can bisect any problems to the exact change that 
caused it - while now we are left to guess about a rather large change:

   6 files changed, 347 insertions(+), 609 deletions(-)

in fact such a big change might warrant 30 or 50 small changes as well - 
the smaller the changes, the better. Such a 1000-lines change we cannot 
reasonably bisect.

	Ingo

-------------->
Linux version 2.6.26-rc3-sched-devel.git (mingo@dione) (gcc version 4.2.2) #483 Tue May 20 22:16:05 CEST 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
 BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
 BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
debug: ignoring loglevel setting.
127MB HIGHMEM available.
896MB LOWMEM available.
  early res: 0 [0-fff] BIOS data page
  early res: 1 [100000-487a8b] TEXT DATA BSS
  early res: 2 [487a8c-48afff] INIT_PG_TABLE
  early res: 3 [9f800-fffff] BIOS reserved
Entering add_active_range(0, 0, 262128) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   229376
  HighMem    229376 ->   262128
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   262128
On node 0 totalpages: 262128
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 1760 pages used for memmap
  Normal zone: 223520 pages, LIFO batch:31
  HighMem zone: 255 pages used for memmap
  HighMem zone: 32497 pages, LIFO batch:7
  Movable zone: 0 pages used for memmap
DMI 2.3 present.
Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260081
Kernel command line: root=/dev/sda1 console=ttyS0,115200 console=tty debug initcall_debug enforcing=0 apic=verbose ignore_loglevel sysrq_always_enabled selinux=0 nmi_watchdog=0
debug: sysrq always enabled.
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 2010.291 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1035232k/1048512k available (1788k kernel code, 12628k reserved, 562k data, 140k init, 131008k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffee000 - 0xfffff000   (  68 kB)
    pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
    vmalloc : 0xf8800000 - 0xff7fe000   ( 111 MB)
    lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
      .init : 0xc034e000 - 0xc0371000   ( 140 kB)
      .data : 0xc02bf20c - 0xc034bcf0   ( 562 kB)
      .text : 0xc0100000 - 0xc02bf20c   (1788 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
CPA: page pool initialized 1 of 1 pages preallocated
SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ hard hang ]


  reply	other threads:[~2008-05-20 20:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-20 15:15 Unify common parts of i8259.c Pavel Machek
2008-05-20 20:47 ` Ingo Molnar [this message]
2008-05-20 22:35   ` Pavel Machek
2008-05-21  9:44   ` Automatical unification " Pavel Machek
2008-05-22 18:30     ` Thomas Gleixner
2008-05-22 20:19       ` Pavel Machek
2008-05-22 20:30         ` Sam Ravnborg
2008-05-22 22:32       ` i8259: fix final uglyness Pavel Machek
2008-05-27  8:46         ` Thomas Gleixner
2008-05-27  8:55           ` Pavel Machek
2008-05-27  9:01             ` Thomas Gleixner
2008-05-28 10:42               ` Pavel Machek
2008-06-02  9:43                 ` Ingo Molnar
2008-05-21  9:47   ` i8259.c: remove #ifdefs around includes Pavel Machek
2008-05-21  9:52   ` i8259.c: remove trivial ifdefs Pavel Machek
2008-05-21  9:57   ` i8259: cleanup codingstyle Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080520204750.GA31409@elte.hu \
    --to=mingo@elte.hu \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@ds2.pg.gda.pl \
    --cc=pavel@suse.cz \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.