[Kgdb-bugreport] kernel stucks while booting with kgdb

[Rajesham G. <raj...@ya...>]

Hi,

I have patched my 2.6.20 kernel (x86_64 arch)
with 2.6.15 kgdb patches. I have been experiencing 
problem in booting my kernel. Booting stucks
immediately after initrd.

I have two serial ports on my machine:
Feb 14 01:23:22 raj kernel: ttyS0 at I/O 0x3f8 (irq =
4) is a 16550A
Feb 14 01:23:22 raj kernel: ttyS1 at I/O 0x2f8 (irq =
3) is a 16550A 

And I have selected port-1 (ttS1) for kgdb purpose.
CONFIG_KGDB=y
# CONFIG_KGDB_CONSOLE is not set
# CONFIG_KGDB_ONLY_MODULES is not set
CONFIG_KGDB_8250_NOMODULE=y
CONFIG_KGDB_8250=y
CONFIG_KGDB_SIMPLE_SERIAL=y
CONFIG_KGDB_BAUDRATE=19200
CONFIG_KGDB_PORT_NUM=1

The machine is always getting stuck at the same point
and the stack trace is:

0xffffffff8037862e in __delay (loops=1806) at
arch/x86_64/lib/delay.c:36
36              }
(gdb) bt
#0  0xffffffff8037862e in __delay (loops=1806) at
arch/x86_64/lib/delay.c:36
#1  0xffffffff803786f1 in __const_udelay (xloops=1806)
    at arch/x86_64/lib/delay.c:43
#2  0xffffffff803d1db3 in serial8250_console_putchar
(port=0xffffffff807b6c20,
    ch=32) at drivers/serial/8250.c:2229
#3  0xffffffff803ceccf in uart_console_write
(port=0xffffffff807b6c20,
    s=0xffffffff8076c060 "on sde1\n", count=57,
    putchar=0xffffffff803d1d70
<serial8250_console_putchar>)
    at drivers/serial/serial_core.c:1785
#4  0xffffffff803d1eca in serial8250_console_write
(co=0x70e,
    s=0xffffffff8076c02f "[   58.367510] md: invalid
raid superblock magic on sde1\n", count=10000) at
drivers/serial/8250.c:2285
#5  0xffffffff80233873 in __call_console_drivers
(start=58223, end=5)
    at kernel/printk.c:332
#6  0xffffffff80233900 in _call_console_drivers
(start=1806, end=58280,
    msg_log_level=9737) at kernel/printk.c:362
#7  0xffffffff802339e5 in call_console_drivers
(start=1806, end=58280)
    at kernel/printk.c:405
#8  0xffffffff80234045 in release_console_sem () at
kernel/printk.c:822
#9  0xffffffff80233e41 in vprintk
(fmt=0xffff810037eb9ab2 "",
    args=0xffffffff80670f20) at kernel/printk.c:614
#10 0xffffffff80233c02 in printk (fmt=0x70e <Address
0x70e out of bounds>)
    at kernel/printk.c:508
#11 0xffffffff8049f867 in super_90_load
(rdev=0xffff81013d4efcc0, refdev=0x0,
    minor_version=9737) at drivers/md/md.c:688
#12 0xffffffff804a2009 in md_import_device
(newdev=8388673, super_format=0,
    super_minor=0) at drivers/md/md.c:2027
#13 0xffffffff804a8175 in autostart_arrays (part=0) at
drivers/md/md.c:5617
#14 0xffffffff804a59d7 in md_ioctl
(inode=0xffff810140049d48, file=0x5,
    cmd=2324, arg=0) at drivers/md/md.c:4237
#15 0xffffffff8036b954 in blkdev_driver_ioctl
(inode=0xffff810140049d48,
    file=0xffff81013d28a0c0, disk=0xffff8101be115a00,
cmd=2324, arg=0)
    at block/ioctl.c:211
#16 0xffffffff8036bb6d in blkdev_ioctl
(inode=0xffff810140049d48,
    file=0xffff81013d28a0c0, cmd=2324, arg=0) at
block/ioctl.c:285
#17 0xffffffff802b780b in block_ioctl (file=0x70e,
cmd=5, arg=2420159946)
    at fs/block_dev.c:1316
#18 0xffffffff8029affe in do_ioctl
(filp=0xffff81013d28a0c0, cmd=2324, arg=0)
    at fs/ioctl.c:28
#19 0xffffffff8029b333 in vfs_ioctl
(filp=0xffff81013d28a0c0, fd=0, cmd=5,
    arg=0) at fs/ioctl.c:153
#20 0xffffffff8029b39d in sys_ioctl (fd=0, cmd=2324,
arg=0) at fs/ioctl.c:173
#21 0xffffffff806e62ef in md_run_setup () at
init/do_mounts_md.c:276
#22 0xffffffff806e30a7 in prepare_namespace () at
init/do_mounts.c:422
#23 0xffffffff802070e4 in init (unused=0x70e) at
init/main.c:756
#24 0xffffffff8020ac78 in child_rip () at current.h:10

After looking at the frame-3, I found that, it is 
actually using serial port-0:
(gdb) f 3
#3  0xffffffff803ceccf in uart_console_write
(port=0xffffffff807b6c20,
    s=0xffffffff8076c060 "on sde1\n", count=57,
    putchar=0xffffffff803d1d70
<serial8250_console_putchar>)
    at drivers/serial/serial_core.c:1785
1785                    putchar(port, *s);

(gdb) p *port
$15 = {lock = {raw_lock = {slock = 0}}, iobase = 1016,
membase = 0x0, irq = 4,
  uartclk = 1843200, fifosize = 16, x_char = 0 '\0',
regshift = 0 '\0',
  iotype = 0 '\0', unused1 = 0 '\0', read_status_mask
= 35,
  ignore_status_mask = 0, info = 0x0, icount = {cts =
0, dsr = 0, rng = 0,
    dcd = 0, rx = 0, tx = 0, frame = 0, overrun = 0,
parity = 0, brk = 0,
    buf_overrun = 0}, cons = 0xffffffff806950e0, sysrq
= 0, flags = 268435520,
  mctrl = 0, timeout = 5, type = 4, ops =
0xffffffff80695020,
  custom_divisor = 0, line = 0, mapbase = 0, dev =
0xffff81013d0f0410,
  hub6 = 0 '\0', unused = "\000\000"}
(gdb) p/x iobase
No symbol "iobase" in current context.
(gdb) p/x port->iobase
$16 = 0x3f8
(gdb) p/x port->irq
$17 = 0x4

Questions I have
1) While I selected port-1 for kgdb why it went to use
   port-0 ?
2) Is it possible that some body is trying to write to
   serial port before its driver is up ?
3) How do we ensure that this serial driver is up (and

   hence this UART is inited properly) before any body
   writes data to this port ?

 


 
____________________________________________________________________________________
Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097