* Re: Problem with current kernel and old sh3 machines
2009-07-24 3:30 Problem with current kernel and old sh3 machines Magnus Damm
@ 2009-07-24 14:49 ` Rafael Ignacio Zurita
2009-07-27 2:40 ` Magnus Damm
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Rafael Ignacio Zurita @ 2009-07-24 14:49 UTC (permalink / raw)
To: linux-sh
Hi Magnus,
On Fri, Jul 24, 2009 at 12:30:06PM +0900, Magnus Damm wrote:
> Hi Rafael,
>
> On Sat, Jun 27, 2009 at 3:46 AM, Rafael Ignacio
> Zurita<rizurita@yahoo.com> wrote:
> > Hello,
> >
> > On Thu, Jun 25, 2009 at 11:12:20AM +0900, Paul Mundt wrote:
> >> On Wed, Jun 24, 2009 at 08:48:50PM -0300, Rafael Ignacio Zurita wrote:
> >> > Current linus linux-2.6 git kernel does not boot in two
> >> > old Sh3 machines: Hp Palmtop 660lx and HP Jornada 680.
> >> >
> >> > After git bisect for a while it finds the problematic commit
> >> > below for the ancient machines:
> >> >
> >> > commit f19900b2e608b604777a74d6d711bbf744657756
> >> > ...
> >> >
> >> > There is not serial output at all when I try to boot.
> >> > I have also selected the sh_tmu driver with CONFIG_SH_TIMER_TMU
> >> > in .config.
> >> >
> >> > Can I try something more? like another option in .config?
> >> >
> >> Well, it does of course boot, but it is possible that you are crashing
> >> somewhere in the early initialization before the serial driver comes up.
> >> What you may wish to do is comment out the early platform tmu
> >> registration in your setup-shxxx.c file for your CPU and use the old TMU
> >> driver for the system timer. This should at least get you past serial
> >> init. Barring that, you really need to get early printk going.
> >
> > On Fri, Jun 26, 2009 at 04:54:39PM +0900, Magnus Damm wrote:
> >>
> >> Like Paul mentioned, you really need early printk to debug this. If
> >> you have time to spend on this let me know and I'll try to direct you
> >> so we can track this down.
> >
> > thanks for the answers.
> >
> > I tried to comment out the platform tmu registration and use
> > the old TMU driver. It was a bit messy, but I managed to build
> > and test. No luck. Of course, it can be something that I did wrong.
> >
> > Anyway, I would like to get early printk, to debug the problem.
> > It looks promising :-)
> >
> > Magnus, I have time to spend on this. Also, I have just started to read
> > about early printk, so if you can help me, I am all ears, and
> > I will try to do my best.
>
> Sorry about the delay. If you still have time, please let me know
> which hardware platform you want to focus on.
No problem. I want to get early printk in sh3 sh7709 (sh770x) + hd64461
cchip, because I would like to work/test with both: Jornada 680 and Palmtop
660lx.
I tried to patch arch/sh/kernel/cpu/sh3/setup-sh770x.c
like you did with sh772 in http://patchwork.kernel.org/patch/23714/ ,
but when I try to boot with "earlyprintk=sh-sci.0" or "earlyprintk=sh-sci.1"
the machine resets after a while without serial output.
Anyway, I don't understand well what I should do, so I decided to wait
you.
Again, thanks in advance if you can help me with this.
Rafael
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Problem with current kernel and old sh3 machines
2009-07-24 3:30 Problem with current kernel and old sh3 machines Magnus Damm
2009-07-24 14:49 ` Rafael Ignacio Zurita
@ 2009-07-27 2:40 ` Magnus Damm
2009-07-30 1:11 ` Rafael Ignacio Zurita
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Magnus Damm @ 2009-07-27 2:40 UTC (permalink / raw)
To: linux-sh
Hi Rafael!
On Fri, Jul 24, 2009 at 11:49 PM, Rafael Ignacio
Zurita<rizurita@yahoo.com> wrote:
> On Fri, Jul 24, 2009 at 12:30:06PM +0900, Magnus Damm wrote:
>> Sorry about the delay. If you still have time, please let me know
>> which hardware platform you want to focus on.
>
> No problem. I want to get early printk in sh3 sh7709 (sh770x) + hd64461
> cchip, because I would like to work/test with both: Jornada 680 and Palmtop
> 660lx.
Step 1: Figure out which serial port to use.
First of all I need to know which serial port that is being used on
your hardware platform(s). In most cases there's a
"console=ttySCX,115200" in CONFIG_CMDLINE for the board defconfig (X
is used to point out the serial port), but the file hp6xx_defconfig
does not have CONFIG_CMDLINE_BOOL set so CONFIG_CMDLINE happens to be
empty.
So please figure out which serial port(s) that are used by your
hardware platform(s). sh7709 has 3 serial ports, your job is to figure
out which port your board(s) are using.
The easiest way to do so is to read some hardware specs, and if you
can't find any then just look at /proc/interrupts on a working kernel
and compare the IRQ number for the serial port with the IRQ numbers in
sci_platform_data[] in your cpu setup file (setup-sh770x.c in this
case). What we want to get is the .mapbase value for the serial port
we should use for early printk.
Please do this for both hardware platforms and email the .mapbase
values to the list.
> I tried to patch arch/sh/kernel/cpu/sh3/setup-sh770x.c
> like you did with sh772 in http://patchwork.kernel.org/patch/23714/ ,
> but when I try to boot with "earlyprintk=sh-sci.0" or "earlyprintk=sh-sci.1"
> the machine resets after a while without serial output.
Aha, thanks for trying that out. That code was my attempt to unify the
early printk code with the serial driver. We're not 100% there yet. =)
I think the in-tree version of early prink should be enough for our
needs at this point though.
Step 2: Get early prink working on an old known working kernel.
When you know the result from Step 1 then edit
arch/sh/kernel/early_printk.c and change both instances of
CONFIG_EARLY_SCIF_CONSOLE_PORT to the .mapbase value. You may also
need to change scif_port.type depending on if your port is a SCI, SCIF
or SCIFA.
Then edit your kernel config and make sure your command line includes
"earlyprintk=serial".
Look at the defconfig for migor_defconfig - both wrt CONFIG_CMDLINE
and early printk config options - CONFIG_EARLY_SCIF_CONSOLE=y +
CONFIG_EARLY_PRINTK=y.
That should be it! Depending on your boot loader you may also need to
comment out code in early_printk.c.
Step 3: Test the early printk code on the old kernel.
Add a BUG() or panic() or printk() with an endless loop somewhere
early. Inside sh770x_devices_setup() may be a good place. Hanging the
kernel there should be early enough for not getting any output without
early printk, but will give you output when early printk is enabled.
You probably want to boot the kernel without mouting any root
partition to avoid checking disks if you need to boot many times....
Step 4: Get early printk working on the broken kernel
This should be farily easy if you've managed to get Step 2 + 3 working. =)
> Anyway, I don't understand well what I should do, so I decided to wait
> you.
>
> Again, thanks in advance if you can help me with this.
Please try out the steps above. Let me know how it works out for you!
I would be happy to give you more detailed information if you get
stuck.
Cheers,
/ magnus
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Problem with current kernel and old sh3 machines
2009-07-24 3:30 Problem with current kernel and old sh3 machines Magnus Damm
2009-07-24 14:49 ` Rafael Ignacio Zurita
2009-07-27 2:40 ` Magnus Damm
@ 2009-07-30 1:11 ` Rafael Ignacio Zurita
2009-07-30 5:25 ` Paul Mundt
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Rafael Ignacio Zurita @ 2009-07-30 1:11 UTC (permalink / raw)
To: linux-sh
Hi Magnus!
On Mon, Jul 27, 2009 at 11:40:18AM +0900, Magnus Damm wrote:
>
> On Fri, Jul 24, 2009 at 11:49 PM, Rafael Ignacio
> Zurita<rizurita@yahoo.com> wrote:
> > On Fri, Jul 24, 2009 at 12:30:06PM +0900, Magnus Damm wrote:
> >> Sorry about the delay. If you still have time, please let me know
> >> which hardware platform you want to focus on.
> >
> > No problem. I want to get early printk in sh3 sh7709 (sh770x) + hd64461
> > cchip, because I would like to work/test with both: Jornada 680 and Palmtop
> > 660lx.
>
> Step 1: Figure out which serial port to use.
>
> First of all I need to know which serial port that is being used on
> your hardware platform(s). In most cases there's a
> "console=ttySCX,115200" in CONFIG_CMDLINE for the board defconfig (X
> is used to point out the serial port), but the file hp6xx_defconfig
> does not have CONFIG_CMDLINE_BOOL set so CONFIG_CMDLINE happens to be
> empty.
>
> So please figure out which serial port(s) that are used by your
> hardware platform(s). sh7709 has 3 serial ports, your job is to figure
> out which port your board(s) are using.
>
> The easiest way to do so is to read some hardware specs, and if you
> can't find any then just look at /proc/interrupts on a working kernel
> and compare the IRQ number for the serial port with the IRQ numbers in
> sci_platform_data[] in your cpu setup file (setup-sh770x.c in this
> case). What we want to get is the .mapbase value for the serial port
> we should use for early printk.
>
> Please do this for both hardware platforms and email the .mapbase
> values to the list.
The serial port being used on the hardware is ttySC1. The hardware
specs and setup-sh770x.c show the .mapbase value 0xa4000150.
> > I tried to patch arch/sh/kernel/cpu/sh3/setup-sh770x.c
> > like you did with sh772 in http://patchwork.kernel.org/patch/23714/ ,
> > but when I try to boot with "earlyprintk=sh-sci.0" or "earlyprintk=sh-sci.1"
> > the machine resets after a while without serial output.
>
> Aha, thanks for trying that out. That code was my attempt to unify the
> early printk code with the serial driver. We're not 100% there yet. =)
> I think the in-tree version of early prink should be enough for our
> needs at this point though.
>
> Step 2: Get early prink working on an old known working kernel.
>
> When you know the result from Step 1 then edit
> arch/sh/kernel/early_printk.c and change both instances of
> CONFIG_EARLY_SCIF_CONSOLE_PORT to the .mapbase value. You may also
> need to change scif_port.type depending on if your port is a SCI, SCIF
> or SCIFA.
>
> Then edit your kernel config and make sure your command line includes
> "earlyprintk=serial".
>
> Look at the defconfig for migor_defconfig - both wrt CONFIG_CMDLINE
> and early printk config options - CONFIG_EARLY_SCIF_CONSOLE=y +
> CONFIG_EARLY_PRINTK=y.
>
> That should be it! Depending on your boot loader you may also need to
> comment out code in early_printk.c.
After some tests, I get early printk working on an old known working kernel
with the patch below :
diff --git a/arch/sh/kernel/cpu/sh3/setup-sh770x.c b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
index 9412d91..9334bad 100644
--- a/arch/sh/kernel/cpu/sh3/setup-sh770x.c
+++ b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
@@ -247,6 +247,8 @@ static struct platform_device *sh770x_devices[] __initdata = {
static int __init sh770x_devices_setup(void)
{
+ for(;;)
+ printk("infinite loop to test early printk\n");
return platform_add_devices(sh770x_devices,
ARRAY_SIZE(sh770x_devices));
}
diff --git a/arch/sh/kernel/early_printk.c b/arch/sh/kernel/early_printk.c
index a952dcf..e08e86e 100644
--- a/arch/sh/kernel/early_printk.c
+++ b/arch/sh/kernel/early_printk.c
@@ -76,8 +76,8 @@ static struct console bios_console = {
static struct uart_port scif_port = {
.type = PORT_SCIF,
- .mapbase = CONFIG_EARLY_SCIF_CONSOLE_PORT,
- .membase = (char __iomem *)CONFIG_EARLY_SCIF_CONSOLE_PORT,
+ .mapbase = 0xa4000150,
+ .membase = (char __iomem *)0xa4000150,
};
static void scif_sercon_putc(int c)
@@ -134,7 +134,7 @@ static void scif_sercon_init(char *s)
sci_out(&scif_port, SCFCR, 0x0030); /* TTRG=b'11 */
sci_out(&scif_port, SCSCR, 0x0030); /* TE, RE */
}
-#elif defined(CONFIG_CPU_SH4)
+#elif defined(CONFIG_CPU_SH4) || defined(CONFIG_CPU_SH3)
#define DEFAULT_BAUD 115200
/*
* Simple SCIF init, primarily aimed at SH7750 and other similar SH-4
@@ -221,7 +221,7 @@ static int __init setup_early_printk(char *buf)
#if !defined(CONFIG_SH_STANDARD_BIOS)
#if defined(CONFIG_CPU_SH4) || defined(CONFIG_CPU_SUBTYPE_SH7720) || \
- defined(CONFIG_CPU_SUBTYPE_SH7721)
+ defined(CONFIG_CPU_SUBTYPE_SH7721) || defined(CONFIG_CPU_SH3)
scif_sercon_init(buf + 6);
#endif
#endif
> Step 3: Test the early printk code on the old kernel.
>
> Add a BUG() or panic() or printk() with an endless loop somewhere
> early. Inside sh770x_devices_setup() may be a good place. Hanging the
> kernel there should be early enough for not getting any output without
> early printk, but will give you output when early printk is enabled.
>
> You probably want to boot the kernel without mouting any root
> partition to avoid checking disks if you need to boot many times....
I have not gotten output from the for(;;) printk();
(in sh770x_devices_setup(void)). When system boots, minicom shows:
Linux version 2.6.30-rc4-hpc (r 9
Boot params:
.... MOUNT_ROOT_RDONLY - 00000000
.... RAMDISK_FLAGS - 00000000
.... ORIG_ROOT_DEV - 00000100
.... LOADER_TYPE - 00000001
.... INITRD_START - 00400000
.... INITRD_SIZE - 00400000
console [sercon0] enabled
Booting machvec: hp6xx
Node 0: start_pfn = 0xd000, low = 0xe000
Zone PFN ranges:
Normal 0x0000d000 -> 0x0000e000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x0000d000 -> 0x0000e000
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line: mem\x16M init=/bin/sh earlyprintk=serial
NR_IRQS:256
PID hash table entries: 64 (order: 6, 256 bytes)
Console: colour dummy device 80x25
console handover: boot [sercon0] -> real [tty0]
and I guess that the system hangs.
Should I try other printks in other places? Suggestions?
> Step 4: Get early printk working on the broken kernel
>
> This should be farily easy if you've managed to get Step 2 + 3 working. =)
Working on that :-)
Thanks a lot for the big help!!, I will continue testing/working on this.
Rafael
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: Problem with current kernel and old sh3 machines
2009-07-24 3:30 Problem with current kernel and old sh3 machines Magnus Damm
` (2 preceding siblings ...)
2009-07-30 1:11 ` Rafael Ignacio Zurita
@ 2009-07-30 5:25 ` Paul Mundt
2009-09-11 4:18 ` Rafael Ignacio Zurita
2009-09-12 3:58 ` Rafael Ignacio Zurita
5 siblings, 0 replies; 7+ messages in thread
From: Paul Mundt @ 2009-07-30 5:25 UTC (permalink / raw)
To: linux-sh
On Wed, Jul 29, 2009 at 10:11:45PM -0300, Rafael Ignacio Zurita wrote:
> Node 0: start_pfn = 0xd000, low = 0xe000
> Zone PFN ranges:
> Normal 0x0000d000 -> 0x0000e000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x0000d000 -> 0x0000e000
> Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
> Kernel command line: mem\x16M init=/bin/sh earlyprintk=serial
> NR_IRQS:256
> PID hash table entries: 64 (order: 6, 256 bytes)
> Console: colour dummy device 80x25
> console handover: boot [sercon0] -> real [tty0]
>
> and I guess that the system hangs.
> Should I try other printks in other places? Suggestions?
>
earlyprintk=serial,keep
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Problem with current kernel and old sh3 machines
2009-07-24 3:30 Problem with current kernel and old sh3 machines Magnus Damm
` (3 preceding siblings ...)
2009-07-30 5:25 ` Paul Mundt
@ 2009-09-11 4:18 ` Rafael Ignacio Zurita
2009-09-12 3:58 ` Rafael Ignacio Zurita
5 siblings, 0 replies; 7+ messages in thread
From: Rafael Ignacio Zurita @ 2009-09-11 4:18 UTC (permalink / raw)
To: linux-sh
Hello,
On Thu, Jul 30, 2009 at 02:25:26PM +0900, Paul Mundt wrote:
> On Wed, Jul 29, 2009 at 10:11:45PM -0300, Rafael Ignacio Zurita wrote:
> > Node 0: start_pfn = 0xd000, low = 0xe000
> > Zone PFN ranges:
> > Normal 0x0000d000 -> 0x0000e000
> > Movable zone start PFN for each node
> > early_node_map[1] active PFN ranges
> > 0: 0x0000d000 -> 0x0000e000
> > Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
> > Kernel command line: mem\x16M init=/bin/sh earlyprintk=serial
> > NR_IRQS:256
> > PID hash table entries: 64 (order: 6, 256 bytes)
> > Console: colour dummy device 80x25
> > console handover: boot [sercon0] -> real [tty0]
> >
> > and I guess that the system hangs.
> > Should I try other printks in other places? Suggestions?
> >
> earlyprintk=serial,keep
Thanks, I get more output for debug.
Now I got the below kernel messages (sorry for the long output):
Linux version 2.6.31-rc4-hpc (rafa@nodo3) (gcc version 3.4.4) #15 PREEMPT Fri Se
p 11 00:42:31 ART 2009
Boot params:
... MOUNT_ROOT_RDONLY - 00000000
... RAMDISK_FLAGS - 00000000
... ORIG_ROOT_DEV - 00000100
... LOADER_TYPE - 00000001
... INITRD_START - 00400000
... INITRD_SIZE - 00400000
console [sercon0] enabled
Booting machvec: hp6xx
Node 0: start_pfn = 0xd000, low = 0xe000
Zone PFN ranges:
Normal 0x0000d000 -> 0x0000e000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x0000d000 -> 0x0000e000
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line: mem\x16MB earlyprintk=serial,keep root=/dev/sda2 psplashú
lse
PID hash table entries: 64 (order: 6, 256 bytes)
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 7536k/16384k available (1145k kernel code, 356k data, 84k init)
NR_IRQS:256
BUG: scheduling while atomic: swapper/0/0x00000002
2 locks held by swapper/0:
#0: (clock_list_sem){......}, at: [<8d009928>] clk_register+0x58/0xf0
#1: (clock_list_sem){......}, at: [<8d009c6c>] clk_get_sys+0x1c/0xd0
Stack: (0x8d15fec0 to 0x8d160000)
fec0: 8d006d6e 8d15fed0 00000000 8d161000 8d00f6e6 8d15fed8 8d11b13e 8d15fee8
fee0: 8d165f30 000000f0 00000001 00000000 8d16118c 8d11befc 8d15ff14 8d161000
ff00: 000000f0 ffffffff ffffff0f 8d165a30 000000f0 8d165a50 8d165a50 8d161000
ff20: 8d15ff14 8d165a50 8d009c6c 8d15ff48 8d0098d0 8d17ccb0 00000000 00000000
ff40: 8d149608 00000000 8d009d3e 8d15ff60 00000000 8d165744 00000000 8d149608
ff60: 8d009012 8d15ff74 8d165744 00000000 8d165744 8d009994 8d15ff80 8d165744
ff80: 8d17cf0e 8d15ff90 00000003 8d165744 8d17cf4a 8d15ffb0 8d18e05c 8d180b10
ffa0: 8d0daf80 8d18e068 8d188c04 8d194530 8d17d242 8d15ffb8 8d17ca98 8d15ffd0
ffc0: 8d0daf80 8d18e068 8d188c04 8d194530 8d17966c 8d15ffdc ffffffff 8d188fd4
ffe0: 8d002024 ac000750 acea98a6 00000000 56125511 64123128 6103d30e 2019e1e0
Call trace:
[<8d006d6e>] dump_stack+0xe/0x2a0
[<8d00f6e6>] __schedule_bug+0x56/0x80
[<8d11b13e>] schedule+0x3de/0x500
[<8d11befc>] mutex_lock_nested+0x13c/0x320
[<8d009c6c>] clk_get_sys+0x1c/0xd0
[<8d0098d0>] clk_register+0x0/0xf0
[<8d17ccb0>] arch_init_clk_ops+0x0/0x30
[<8d009d3e>] clk_get+0x1e/0x100
[<8d009012>] set_bus_parent+0x12/0x30
[<8d009994>] clk_register+0xc4/0xf0
[<8d17cf0e>] cpg_clk_init+0x3e/0x70
[<8d17cf4a>] arch_clk_init+0xa/0x20
[<8d180b10>] __alloc_bootmem+0x0/0x20
[<8d0daf80>] strlen+0x0/0x58
[<8d17d242>] clk_init+0x12/0xc0
[<8d17ca98>] time_init+0x18/0xc0
[<8d0daf80>] strlen+0x0/0x58
[<8d17966c>] start_kernel+0x15c/0x570
[<8d002024>] _stext+0x24/0x30
2 locks held by swapper/0:
#0: (clock_list_sem){......}, at: [<8d009928>] clk_register+0x58/0xf0
#1: (clock_list_sem){......}, at: [<8d009c6c>] clk_get_sys+0x1c/0xd0
Unable to handle kernel NULL pointer dereference at virtual address 0000001c
pc = 8d00c65c
*pde = 00000000
Oops: 0000 [#1]
Pid : 0, Comm: swapper
CPU : 0 Not tainted (2.6.31-rc4-hpc #15)
PC is at set_next_entity+0xc/0x70
PR is at pick_next_task_fair+0x3e/0xb0
PC : 8d00c65c SP : 8d15fec4 SR : 400000f1 TEA : 0000001c
R0 : 00000000 R1 : 8d00c650 R2 : ffffffff R3 : 8d165f70
R4 : 8d165f80 R5 : 00000000 R6 : fff00000 R7 : ffffffff
R8 : 00000000 R9 : 8d165f80 R10 : 8d165f30 R11 : ffffffff
R12 : 8d165f30 R13 : 8d161000 R14 : 8d15fed4
MACH: 00000000 MACL: 00000007 GBR : 8c009800 PR : 8d00cd9e
Call trace:
[<8d00cd9e>] pick_next_task_fair+0x3e/0xb0
[<8d11aeb2>] schedule+0x152/0x500
[<8d11befc>] mutex_lock_nested+0x13c/0x320
[<8d009c6c>] clk_get_sys+0x1c/0xd0
[<8d0098d0>] clk_register+0x0/0xf0
[<8d17ccb0>] arch_init_clk_ops+0x0/0x30
[<8d009d3e>] clk_get+0x1e/0x100
[<8d009012>] set_bus_parent+0x12/0x30
[<8d009994>] clk_register+0xc4/0xf0
[<8d17cf0e>] cpg_clk_init+0x3e/0x70
[<8d17cf4a>] arch_clk_init+0xa/0x20
[<8d180b10>] __alloc_bootmem+0x0/0x20
[<8d0daf80>] strlen+0x0/0x58
[<8d17d242>] clk_init+0x12/0xc0
[<8d17ca98>] time_init+0x18/0xc0
[<8d0daf80>] strlen+0x0/0x58
[<8d17966c>] start_kernel+0x15c/0x570
[<8d002024>] _stext+0x24/0x30
INFO: lockdep is turned off.
Process: swapper (pid: 0, stack limit = 8d15e001)
Stack: (0x8d15fec4 to 0x8d160000)
fec0: 8d00cd9e 8d15fed4 8d165f80 00000000 8d11aeb2 8d15fee8 8d161000
fee0: 8d165f30 8d16632c 00000001 00000000 8d161188 8d11befc 8d15ff14 8d161000
ff00: 000000f0 ffffffff ffffff0f 8d165a30 000000f0 8d165a50 8d165a50 8d161000
ff20: 8d15ff14 8d165a50 8d009c6c 8d15ff48 8d0098d0 8d17ccb0 00000000 00000000
ff40: 8d149608 00000000 8d009d3e 8d15ff60 00000000 8d165744 00000000 8d149608
ff60: 8d009012 8d15ff74 8d165744 00000000 8d165744 8d009994 8d15ff80 8d165744
ff80: 8d17cf0e 8d15ff90 00000003 8d165744 8d17cf4a 8d15ffb0 8d18e05c 8d180b10
ffa0: 8d0daf80 8d18e068 8d188c04 8d194530 8d17d242 8d15ffb8 8d17ca98 8d15ffd0
ffc0: 8d0daf80 8d18e068 8d188c04 8d194530 8d17966c 8d15ffdc ffffffff 8d188fd4
ffe0: 8d002024 ac000750 acea98a6 00000000 56125511 64123128 6103d30e 2019e1e0
---[ end trace 4eaa2a86a8e2da22 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Stack: (0x8d15fd28 to 0x8d160000)
fd20: 8d006d6e 8d15fd38 8d18f260 8d0153c0 8d013fe8 8d15fd40
fd40: 8d017068 8d15fd6c 8d15fe68 8d0e3f40 00000000 0000000b 8d161000 ffffffff
fd60: 00000001 8d014dfc 00000000 8d0e3f40 00000000 8d149970 8d15fe68 8d0061bc
fd80: 8d15fd9c 8d15fe68 8d0e3f40 00000000 8d149970 8d15fe68 8d0153c0 8d00af9c
fda0: 8d15fdb8 8d161000 8d15fea8 0000001c 8d0153c0 00000000 00000023 8d014990
fdc0: 8d161000 8d193783 8d0150c8 8d15fdd0 8d161000 8d193765 8d0150c8 8d15fde0
fde0: 8d014dfc 8d15fdf0 8d014eb6 8d15fdf0 8d015116 8d15fe10 00000004 8d014990
fe00: 8d0153c0 8d193761 8d0150c8 8d15fe10 8d15fe14 8d014dfc 8d15fe24 8d014eb6
fe20: 00000004 000000f0 8d15fe44 00000004 8d0153d4 8d15fe50 00000000 00030001
fe40: 8d161000 00000002 8d0070e4 8d15fed4 8d161000 8d165f30 ffffffff 8d0070e4
fe60: 0000001c 00000000 00000000 8d00c650 ffffffff 8d165f70 8d165f80 00000000
fe80: fff00000 ffffffff 00000000 8d165f80 8d165f30 ffffffff 8d165f30 8d161000
fea0: 8d15fed4 8d15fec4 8d00c65c 8d00cd9e 400000f1 8c009800 00000000 00000007
fec0: ffffffff 8d00cd9e 8d15fed4 8d165f80 00000000 8d11aeb2 8d15fee8 8d161000
fee0: 8d165f30 8d16632c 00000001 00000000 8d161188 8d11befc 8d15ff14 8d161000
ff00: 000000f0 ffffffff ffffff0f 8d165a30 000000f0 8d165a50 8d165a50 8d161000
ff20: 8d15ff14 8d165a50 8d009c6c 8d15ff48 8d0098d0 8d17ccb0 00000000 00000000
ff40: 8d149608 00000000 8d009d3e 8d15ff60 00000000 8d165744 00000000 8d149608
ff60: 8d009012 8d15ff74 8d165744 00000000 8d165744 8d009994 8d15ff80 8d165744
ff80: 8d17cf0e 8d15ff90 00000003 8d165744 8d17cf4a 8d15ffb0 8d18e05c 8d180b10
ffa0: 8d0daf80 8d18e068 8d188c04 8d194530 8d17d242 8d15ffb8 8d17ca98 8d15ffd0
ffc0: 8d0daf80 8d18e068 8d188c04 8d194530 8d17966c 8d15ffdc ffffffff 8d188fd4
ffe0: 8d002024 ac000750 acea98a6 00000000 56125511 64123128 6103d30e 2019e1e0
Call trace:
[<8d006d6e>] dump_stack+0xe/0x2a0
[<8d0153c0>] printk+0x0/0x30
[<8d013fe8>] panic+0x48/0x140
[<8d017068>] do_exit+0x448/0x660
[<8d0e3f40>] bust_spinlocks+0x0/0x60
[<8d014dfc>] release_console_sem+0xdc/0x240
[<8d0e3f40>] bust_spinlocks+0x0/0x60
[<8d0061bc>] die+0xfc/0x160
[<8d0e3f40>] bust_spinlocks+0x0/0x60
[<8d0153c0>] printk+0x0/0x30
[<8d00af9c>] do_page_fault+0x22c/0x3d0
[<8d0153c0>] printk+0x0/0x30
[<8d014990>] emit_log_char+0x0/0x70
[<8d0150c8>] vprintk+0x118/0x410
[<8d0150c8>] vprintk+0x118/0x410
[<8d014dfc>] release_console_sem+0xdc/0x240
[<8d014eb6>] release_console_sem+0x196/0x240
[<8d015116>] vprintk+0x166/0x410
[<8d014990>] emit_log_char+0x0/0x70
[<8d0153c0>] printk+0x0/0x30
[<8d0150c8>] vprintk+0x118/0x410
[<8d014dfc>] release_console_sem+0xdc/0x240
[<8d014eb6>] release_console_sem+0x196/0x240
[<8d0153d4>] printk+0x14/0x30
[<8d0070e4>] ret_from_exception+0x0/0x8
[<8d0070e4>] ret_from_exception+0x0/0x8
[<8d00c650>] set_next_entity+0x0/0x70
[<8d00c65c>] set_next_entity+0xc/0x70
[<8d00cd9e>] pick_next_task_fair+0x3e/0xb0
[<8d00cd9e>] pick_next_task_fair+0x3e/0xb0
[<8d11aeb2>] schedule+0x152/0x500
[<8d11befc>] mutex_lock_nested+0x13c/0x320
[<8d009c6c>] clk_get_sys+0x1c/0xd0
[<8d0098d0>] clk_register+0x0/0xf0
[<8d17ccb0>] arch_init_clk_ops+0x0/0x30
[<8d009d3e>] clk_get+0x1e/0x100
[<8d009012>] set_bus_parent+0x12/0x30
[<8d009994>] clk_register+0xc4/0xf0
[<8d17cf0e>] cpg_clk_init+0x3e/0x70
[<8d17cf4a>] arch_clk_init+0xa/0x20
[<8d180b10>] __alloc_bootmem+0x0/0x20
[<8d0daf80>] strlen+0x0/0x58
[<8d17d242>] clk_init+0x12/0xc0
[<8d17ca98>] time_init+0x18/0xc0
[<8d0daf80>] strlen+0x0/0x58
[<8d17966c>] start_kernel+0x15c/0x570
[<8d002024>] _stext+0x24/0x30
INFO: lockdep is turned off.
The important message (I guess) is :
2 locks held by swapper/0:
#0: (clock_list_sem){......}, at: [<8d009928>] clk_register+0x58/0xf0
#1: (clock_list_sem){......}, at: [<8d009c6c>] clk_get_sys+0x1c/0xd0
Unable to handle kernel NULL pointer dereference at virtual address 0000001c
So I read for a while arch/sh/kernel/cpu/clock.c
trying to understand if I see some problem. Both, int clk_register(struct clk *clk)
and struct clk *clk_get_sys(const char *dev_id, const char *con_id)
do mutex_lock(&clock_list_sem) and mutex_unlock(&clock_list_sem).
Then, I did this crazy change below:
diff -upr linux-2.6.orig/arch/sh/kernel/cpu/clock.c linux-2.6.new/arch/sh/kernel/cpu/clock.c
--- linux-2.6.orig/arch/sh/kernel/cpu/clock.c 2009-09-11 01:09:35.000000000 -0300
+++ linux-2.6.new/arch/sh/kernel/cpu/clock.c 2009-09-11 01:12:01.000000000 -0300
@@ -266,7 +266,7 @@ int clk_register(struct clk *clk)
if (clk->node.next || clk->node.prev)
return 0;
- mutex_lock(&clock_list_sem);
+ /* mutex_lock(&clock_list_sem); */
INIT_LIST_HEAD(&clk->children);
clk->usecount = 0;
@@ -279,7 +279,7 @@ int clk_register(struct clk *clk)
list_add(&clk->node, &clock_list);
if (clk->ops && clk->ops->init)
clk->ops->init(clk);
- mutex_unlock(&clock_list_sem);
+ /* mutex_unlock(&clock_list_sem); */
return 0;
}
and after building the kernel boots and goes further:
Linux version 2.6.31-rc4-hpc (rafa@nodo3) (gcc version 3.4.4) #16 PREEMPT Fri Sep 9
Boot params:
... MOUNT_ROOT_RDONLY - 00000000
... RAMDISK_FLAGS - 00000000
... ORIG_ROOT_DEV - 00000100
... LOADER_TYPE - 00000001
... INITRD_START - 00400000
... INITRD_SIZE - 00400000
console [sercon0] enabled
Booting machvec: hp6xx
Node 0: start_pfn = 0xd000, low = 0xe000
Zone PFN ranges:
Normal 0x0000d000 -> 0x0000e000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x0000d000 -> 0x0000e000
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line: mem\x16MB earlyprintk=serial,keep root=/dev/sda2 psplashúlse
PID hash table entries: 64 (order: 6, 256 bytes)
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 7536k/16384k available (1145k kernel code, 356k data, 84k init)
NR_IRQS:256
sh_tmu: TMU0 used for clock events
sh_tmu: TMU0 used for periodic clock events
sh_tmu: TMU1 used as clock source
Console: colour dummy device 80x25
console [tty0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 48
... MAX_LOCKDEP_KEYS: 8191
... CLASSHASH_SIZE: 4096
... MAX_LOCKDEP_ENTRIES: 16384
... MAX_LOCKDEP_CHAINS: 32768
... CHAINHASH_SIZE: 16384
memory used by lock dependency info: 3487 kB
per task-struct memory footprint: 1152 bytes
Calibrating delay loop (skipped)... 0.00 BogoMIPS PRESET (lpj=0)
Mount-cache hash table entries: 512
CPU: SH7729
bio: create slab <bio-0> at 0
sh_tmu: TMU0 used for oneshot clock events
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
BUG: Bad page state in process swapper pfn:0d562
page:8d88bc40 flags:00080000 count:0 mapcount:0 mapping:(null) index:0
Stack: (0x8dc1fc40 to 0x8dc20000)
fc40: 8d006d6e 8dc1fc50 8d55c99c 8d88bc40 8d044d76 8dc1fc58 8d047456 8d047416
fc60: 8dc1fc78 00000000 8d178150 8d800000 ffffff0f 8d88bc40 8d0475cc 8dc1fc98
fc80: 80000000 ffe60000 8d400000 8d800000 ffffff0f 8d562000 8d04761c 8dc1fca0
fca0: 8d04768e 8dc1fca8 8d00a44e 8dc1fcb0 8d17be7e 8dc1fcd0 8dc4b000 ffffffff
fcc0: 8d1489a8 8dc4b000 8d18e094 8d18e098 8d17c034 8dc1fce0 00000000 00000000
fce0: 8dc1fd04 8d0aea34 00000001 00000004 000241ed 00000000 00000000 00000000
fd00: 00001000 00000000 4a723e40 00000000 4a723e40 00000000 386d4380 11e443cf
fd20: 00000000 00000000 00000000 8d00208c 8dc1fd4c 00000000 00000000 8dc1ff2c
fd40: 8d18b6f0 8d002050 8d18b5bc 8d157e00 8d157e1c 00000002 00000010 00000002
fd60: fffffffa 0000000a 00000001 ffffffff 00000010 00000002 ffffffff 0000000a
fd80: ffffffff ffffffff 00000001 00000000 00000000 00000000 00000000 0000037c
fda0: ffffffab ffffffff 8d1679d8 00000000 00000000 8dc1d020 00000000 8d165f40
fdc0: 00000000 00000000 8dc1d020 00000000 8d167a10 8d03849c 8dc1fe04 8d193cb0
fde0: 00000000 00000000 8dc1d020 00000000 8d165f80 8d03849c 8d170b90 00000000
fe00: 00000000 8dc1d020 00000000 0000037c 8d03849c 8dc1fe40 00000102 00000020
fe20: 8d166578 8d063858 8d063858 8dc1fe48 00000102 00000020 8dc21bd0 8d172398
fe40: 00000000 8d172398 00000000 00000000 8dc1d020 00000001 8dc1fe84 8d03849c
fe60: 8dc1fe8c 8d172378 00000032 8dc13524 00000000 0000037c 000000f0 00000001
fe80: 00000001 00000000 8d0dbc78 8d11d7c4 8d11dc18 8dc1feac 8d063858 8dc1feb8
fea0: 8d172378 8d17236c 00000000 00000000 8dc1d020 00000000 8d0dca50 8d03849c
fec0: 8dc1feec 8dc3d230 8dc3d1b0 8d0dc8b0 00000000 0000037c 00000000 00000001
fee0: 00000000 00000000 8d0a907a 8d11d764 8d11dca4 8dc1ff0c 8dc3d1b0 8d0dc8b0
ff00: 8d11dcaa 8dc1ff0c 8d17235c 8d0a90b2 8dc1ff18 00000000 00000032 8d0a93b2
ff20: 8dc1ff3c 00000000 00000000 8d03eab0 0000003c 8d55c948 8dc3d1b0 8dc3d230
ff40: 8d03eb1a 8dc1ff4c 8d16a318 00003036 00000000 8d170000 8d03ebfe 8d17bec0
ff60: 00000001 8d179b00 8dc1ff84 00000000 00000000 8d18b538 8d18b6f0 8d002050
ff80: 8d18b5bc 8d003a38 8dc1ff9c 00000000 00000000 00000000 00000000 00000000
ffa0: 00000000 00000000 00000000 00000000 00000000 00000000 8d179a80 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 8dc1ffa4 8d003a30 00000000 40000000 00000000 00000000 00000000 00000000
Call trace:
[<8d006d6e>] dump_stack+0xe/0x2a0
[<8d044d76>] bad_page+0x76/0x140
[<8d047456>] free_hot_cold_page+0x196/0x290
[<8d047416>] free_hot_cold_page+0x156/0x290
[<8d0475cc>] free_hot_page+0xc/0x20
[<8d04761c>] __free_pages+0x3c/0x70
[<8d04768e>] free_pages+0x3e/0x60
[<8d00a44e>] free_initrd_mem+0x8e/0x100
[<8d17be7e>] free_initrd+0x1e/0x60
[<8d17c034>] populate_rootfs+0x174/0x280
[<8d0aea34>] sysfs_add_file_mode+0x44/0xc0
[<8d00208c>] do_one_initcall+0x3c/0x200
[<8d002050>] do_one_initcall+0x0/0x200
[<8d03849c>] lock_acquire+0x4c/0x90
[<8d03849c>] lock_acquire+0x4c/0x90
[<8d03849c>] lock_acquire+0x4c/0x90
[<8d063858>] kmem_cache_free+0x28/0xa0
[<8d063858>] kmem_cache_free+0x28/0xa0
[<8d03849c>] lock_acquire+0x4c/0x90
[<8d0dbc78>] get_from_free_list+0x18/0x50
[<8d11d7c4>] _spin_lock_irqsave+0x44/0x60
[<8d11dc18>] _spin_unlock_irqrestore+0x18/0x90
[<8d063858>] kmem_cache_free+0x28/0xa0
[<8d0dca50>] ida_get_new_above+0x140/0x200
[<8d03849c>] lock_acquire+0x4c/0x90
[<8d0dc8b0>] ida_pre_get+0x0/0x60
[<8d0a907a>] proc_register+0x8a/0x1d0
[<8d11d764>] _spin_lock+0x34/0x50
[<8d11dca4>] _spin_unlock+0x14/0x60
[<8d0dc8b0>] ida_pre_get+0x0/0x60
[<8d11dcaa>] _spin_unlock+0x1a/0x60
[<8d0a90b2>] proc_register+0xc2/0x1d0
[<8d0a93b2>] create_proc_entry+0x42/0xb0
[<8d03eab0>] register_irq_proc+0x0/0xb0
[<8d03eb1a>] register_irq_proc+0x6a/0xb0
[<8d03ebfe>] init_irq_proc+0x4e/0x90
[<8d17bec0>] populate_rootfs+0x0/0x280
[<8d179b00>] kernel_init+0x80/0x140
[<8d002050>] do_one_initcall+0x0/0x200
[<8d003a38>] kernel_thread_helper+0x8/0x20
[<8d179a80>] kernel_init+0x0/0x140
[<8d003a30>] kernel_thread_helper+0x0/0x20
no locks held by swapper/1.
Disabling lock debugging due to kernel taint
Freeing initrd memory: 4096k freed
HD64461 configured at 0xb0000000 on irq 36(mapped into 64 to 79)
msgmni has been set to 22
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
SuperH SCI(F) driver initialized
sh-sci: ttySC0 at MMIO 0xfffffe80 (irq = 23) is a sci
sh-sci: ttySC1 at MMIO 0xa4000150 (irq = 56) is a scif
sh-sci: ttySC2 at MMIO 0xa4000140 (irq = 52) is a irda
brd: module loaded
sh_tmu: TMU0 kept as earlytimer
sh_tmu: TMU1 kept as earlytimer
RAMDISK: Couldn't find valid RAM disk image starting at 0.
VFS: Cannot open root device "sda2" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Stack: (0x8dc1fed4 to 0x8dc20000)
fec0: 8d006d6e 8dc1fee4 8d18f260
fee0: 8d015390 8d013fb8 8dc1feec 8d179dfe 8dc1ff18 00000000 00008000 000002bc
ff00: 8dc3a000 8d015390 8dc3a000 8dc1ff18 8d11a0a2 00000000 6e6b6e75 2d6e776f
ff20: 636f6c62 2c30286b 00002930 8dc3a000 8dc3a000 8d072be6 8d148468 8d17a124
ff40: 8dc1ff5c 00000000 00000000 8d002390 8d18b6f0 8d148468 00000000 8d17a2c2
ff60: 8dc1ff6c 8d002050 8d18e07c 8d179b4a 8dc1ff84 8d18b538 8d18b6f0 8d002050
ff80: 8d18e070 8d003a38 8dc1ff9c 00000000 00000000 00000000 00000000 00000000
ffa0: 00000000 00000000 00000000 00000000 00000000 00000000 8d179a80 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 8dc1ffa4 8d003a30 00000000 40000000 00000000 00000000 00000000 00000000
Call trace:
[<8d006d6e>] dump_stack+0xe/0x2a0
[<8d015390>] printk+0x0/0x30
[<8d013fb8>] panic+0x48/0x140
[<8d179dfe>] mount_block_root+0xde/0x2e0
[<8d015390>] printk+0x0/0x30
[<8d11a0a2>] klist_next+0x62/0xd0
[<8d072be6>] sys_mknod+0x16/0x30
[<8d17a124>] mount_root+0x44/0x70
[<8d002390>] name_to_dev_t+0x0/0xc70
[<8d17a2c2>] prepare_namespace+0x172/0x230
[<8d002050>] do_one_initcall+0x0/0x200
[<8d179b4a>] kernel_init+0xca/0x140
[<8d002050>] do_one_initcall+0x0/0x200
[<8d003a38>] kernel_thread_helper+0x8/0x20
[<8d179a80>] kernel_init+0x0/0x140
[<8d003a30>] kernel_thread_helper+0x0/0x20
INFO: lockdep is turned off.
Now, I don't know how to continue fixing properly the problem. Suggestions?
Rafael
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Problem with current kernel and old sh3 machines
2009-07-24 3:30 Problem with current kernel and old sh3 machines Magnus Damm
` (4 preceding siblings ...)
2009-09-11 4:18 ` Rafael Ignacio Zurita
@ 2009-09-12 3:58 ` Rafael Ignacio Zurita
5 siblings, 0 replies; 7+ messages in thread
From: Rafael Ignacio Zurita @ 2009-09-12 3:58 UTC (permalink / raw)
To: linux-sh
Hi,
On Fri, Sep 11, 2009 at 01:18:41AM -0300, Rafael Ignacio Zurita wrote:
> On Thu, Jul 30, 2009 at 02:25:26PM +0900, Paul Mundt wrote:
> > On Wed, Jul 29, 2009 at 10:11:45PM -0300, Rafael Ignacio Zurita wrote:
> > > Node 0: start_pfn = 0xd000, low = 0xe000
> > > Zone PFN ranges:
> > > Normal 0x0000d000 -> 0x0000e000
> > > Movable zone start PFN for each node
> > > early_node_map[1] active PFN ranges
> > > 0: 0x0000d000 -> 0x0000e000
> > > Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
> > > Kernel command line: mem\x16M init=/bin/sh earlyprintk=serial
> > > NR_IRQS:256
> > > PID hash table entries: 64 (order: 6, 256 bytes)
> > > Console: colour dummy device 80x25
> > > console handover: boot [sercon0] -> real [tty0]
> > >
> > > and I guess that the system hangs.
> > > Should I try other printks in other places? Suggestions?
> > >
> > earlyprintk=serial,keep
>
> Thanks, I get more output for debug.
> Now I got the below kernel messages (sorry for the long output):
>
...
>
> The important message (I guess) is :
>
> 2 locks held by swapper/0:
> #0: (clock_list_sem){......}, at: [<8d009928>] clk_register+0x58/0xf0
> #1: (clock_list_sem){......}, at: [<8d009c6c>] clk_get_sys+0x1c/0xd0
> Unable to handle kernel NULL pointer dereference at virtual address 0000001c
>
>
> So I read for a while arch/sh/kernel/cpu/clock.c
> trying to understand if I see some problem. Both, int clk_register(struct clk *clk)
> and struct clk *clk_get_sys(const char *dev_id, const char *con_id)
> do mutex_lock(&clock_list_sem) and mutex_unlock(&clock_list_sem).
>
> Then, I did this crazy change below:
>
> diff -upr linux-2.6.orig/arch/sh/kernel/cpu/clock.c linux-2.6.new/arch/sh/kernel/cpu/clock.c
> --- linux-2.6.orig/arch/sh/kernel/cpu/clock.c 2009-09-11 01:09:35.000000000 -0300
> +++ linux-2.6.new/arch/sh/kernel/cpu/clock.c 2009-09-11 01:12:01.000000000 -0300
> @@ -266,7 +266,7 @@ int clk_register(struct clk *clk)
> if (clk->node.next || clk->node.prev)
> return 0;
>
> - mutex_lock(&clock_list_sem);
> + /* mutex_lock(&clock_list_sem); */
>
> INIT_LIST_HEAD(&clk->children);
> clk->usecount = 0;
> @@ -279,7 +279,7 @@ int clk_register(struct clk *clk)
> list_add(&clk->node, &clock_list);
> if (clk->ops && clk->ops->init)
> clk->ops->init(clk);
> - mutex_unlock(&clock_list_sem);
> + /* mutex_unlock(&clock_list_sem); */
>
> return 0;
> }
>
>
> and after building the kernel boots and goes further:
I did printks and I tried to do a tracing :
From arch/sh/kernel/cpu/clock-cpg.c :
static struct clk *onchip_clocks[] = {
&master_clk,
&peripheral_clk,
&bus_clk,
&cpu_clk,
};
int __init __deprecated cpg_clk_init(void)
{
int i, ret = 0;
for (i = 0; i < ARRAY_SIZE(onchip_clocks); i++) {
struct clk *clk = onchip_clocks[i];
arch_init_clk_ops(&clk->ops, i);
if (clk->ops)
ret |= clk_register(clk);
}
return ret;
}
When i=3, clk_register() for cpu_clk looks like a breakage.
clk_register() from arch/sh/kernel/cpu/clock.c says :
int clk_register(struct clk *clk)
{
if (clk = NULL || IS_ERR(clk))
return -EINVAL;
/*
* trap out already registered clocks
*/
if (clk->node.next || clk->node.prev)
return 0;
mutex_lock(&clock_list_sem);
INIT_LIST_HEAD(&clk->children);
clk->usecount = 0;
if (clk->parent)
list_add(&clk->sibling, &clk->parent->children);
else
list_add(&clk->sibling, &root_clks);
list_add(&clk->node, &clock_list);
if (clk->ops && clk->ops->init)
clk->ops->init(clk);
mutex_unlock(&clock_list_sem);
return 0;
}
EXPORT_SYMBOL_GPL(clk_register);
There is a first mutex_lock, and then, it calls clk->ops->init(clk).
From arch/sh/kernel/cpu/sh3/clock-sh7709.c :
static void set_bus_parent(struct clk *clk)
{
struct clk *bus_clk = clk_get(NULL, "bus_clk");
clk->parent = bus_clk;
clk_put(bus_clk);
}
static struct clk_ops sh7709_cpu_clk_ops = {
.init = set_bus_parent,
.recalc = cpu_clk_recalc,
};
static struct clk_ops *sh7709_clk_ops[] = {
&sh7709_master_clk_ops,
&sh7709_module_clk_ops,
&sh7709_bus_clk_ops,
&sh7709_cpu_clk_ops,
};
set_bus_parent() calls clk_get(). Then from
arch/sh/kernel/cpu/clock.c :
struct clk *clk_get(struct device *dev, const char *id)
{
const char *dev_id = dev ? dev_name(dev) : NULL;
struct clk *p, *clk = ERR_PTR(-ENOENT);
int idno;
clk = clk_get_sys(dev_id, id);
...
struct clk *clk_get_sys(const char *dev_id, const char *con_id)
{
struct clk *clk;
mutex_lock(&clock_list_sem);
clk = clk_find(dev_id, con_id);
mutex_unlock(&clock_list_sem);
return clk ? clk : ERR_PTR(-ENOENT);
}
EXPORT_SYMBOL_GPL(clk_get_sys);
Again, a new mutex_lock.
Is that correct? I mean, printks stop with the last
for (i = 0; i < ARRAY_SIZE(onchip_clocks); i++) {
in int __init __deprecated cpg_clk_init(void)
So it looks for me like two locks before the first one unlocks.
If I am reading well, that should not be a proper situation right?
There I would like to see the two below lines
if (clk->ops && clk->ops->init)
clk->ops->init(clk);
out from lock-unlock section. Thoughts?
Rafael
^ permalink raw reply [flat|nested] 7+ messages in thread