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 ?
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html
|