public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox