* [PATCH] correct cacheflush loop in zImage
From: Olaf Hering @ 2006-03-04 12:15 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Correct the loop for cacheflush. No idea where I copied the code from,
but the original does not work correct. Maybe the flush is not needed.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/boot/crt0.S | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/boot/crt0.S
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/boot/crt0.S
+++ linux-2.6.16-rc5-olh/arch/powerpc/boot/crt0.S
@@ -45,7 +45,8 @@ _zimage_start:
bdnz 2b
/* Do a cache flush for our text, in case OF didn't */
-3: lis r9,_start@h
+3: lis r9,_start@ha
+ addi r9,r9,_start@l
add r9,r0,r9
lis r8,_etext@ha
addi r8,r8,_etext@l
@@ -53,7 +54,7 @@ _zimage_start:
4: dcbf r0,r9
icbi r0,r9
addi r9,r9,0x20
- cmplwi 0,r9,8
+ cmplw cr0,r9,r8
blt 4b
sync
isync
^ permalink raw reply
* Re: [PATCH] correct cacheflush loop in zImage
From: Olaf Hering @ 2006-03-04 12:58 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
In-Reply-To: <20060304121540.GA30106@suse.de>
On Sat, Mar 04, Olaf Hering wrote:
>
> Correct the loop for cacheflush. No idea where I copied the code from,
> but the original does not work correct. Maybe the flush is not needed.
>
> Signed-off-by: Olaf Hering <olh@suse.de>
>
> arch/powerpc/boot/crt0.S | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.16-rc5-olh/arch/powerpc/boot/crt0.S
> ===================================================================
> --- linux-2.6.16-rc5-olh.orig/arch/powerpc/boot/crt0.S
> +++ linux-2.6.16-rc5-olh/arch/powerpc/boot/crt0.S
> @@ -45,7 +45,8 @@ _zimage_start:
> bdnz 2b
>
> /* Do a cache flush for our text, in case OF didn't */
> -3: lis r9,_start@h
> +3: lis r9,_start@ha
> + addi r9,r9,_start@l
> add r9,r0,r9
I think this part is not required. Segments must be 64k aligned, so the
lower bits will be always zero (modulo the _start offset into .text)
^ permalink raw reply
* Re: incorrect rmo_top handling in prom_init
From: Olaf Hering @ 2006-03-04 15:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1141342541.13565.6.camel@localhost.localdomain>
On Fri, Mar 03, Benjamin Herrenschmidt wrote:
> On Thu, 2006-03-02 at 19:55 +0100, Olaf Hering wrote:
> > My iBook1 has 2 memory regions in reg. Depending on how I boot it
> > (vmlinux+initrd) or zImage.initrd, it will not boot with current Linus
> > tree.
> > rmo_top should be 160MB instead of 32MB.
>
> Does that fix it ?
Yes.
^ permalink raw reply
* Re: Different Page Size Support in Linux on PPC870
From: Dan Malek @ 2006-03-04 17:11 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201C47BE3@us-bv-m23.global.tektronix.net>
On Mar 3, 2006, at 9:38 PM, <atul.sabharwal@exgate.tek.com> wrote:
> On PPC870, does the kernel only support 4K pages?
The CONFIG_PIN_TLB will get you 8M pages for the kernel
space, and likely be a good solution for you. We have experimented
with various dynamic replace methods for the past several years,
but I still haven't found a solution I like.
-- Dan
^ permalink raw reply
* [PATCH] return to OF via trap, not exit
From: Olaf Hering @ 2006-03-04 19:10 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Do not call prom exit prom_panic. It clears the screen and the exit message is lost.
On some (or all?) pmacs it causes another crash when OF tries to print the
date and time in its banner.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/prom_init.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
@@ -398,7 +398,9 @@ static void __init __attribute__((noretu
#endif
prom_print(reason);
/* ToDo: should put up an SRC here on p/iSeries */
- call_prom("exit", 0, 0);
+ /* Do not call exit because it clears the screen on pmac
+ * it also causes some sort of double-fault on early pmacs */
+ asm("trap\n");
for (;;) /* should never get here */
;
^ permalink raw reply
* cross tools for the 440gp
From: Ralph Blach @ 2006-03-05 1:32 UTC (permalink / raw)
To: linuxppc-embedded
are there any prebuild cross compilers for the 440gp processors
that would compile a 2.6 kernel?
If so, could I get some pointer to where they are?
Thanks
Chip
^ permalink raw reply
* cross tools for the 440gp
From: Ralph Blach @ 2006-03-05 1:32 UTC (permalink / raw)
To: linuxppc-embedded
are there any prebuild cross compilers for the 440gp processors
that would compile a 2.6 kernel?
If so, could I get some pointer to where they are?
Thanks
Chip
^ permalink raw reply
* Re: cross tools for the 440gp
From: David Hawkins @ 2006-03-05 4:30 UTC (permalink / raw)
To: Ralph Blach; +Cc: linuxppc-embedded
In-Reply-To: <440A3FB4.6060806@blach.dnsalias.org>
Ralph Blach wrote:
> are there any prebuild cross compilers for the 440gp processors
> that would compile a 2.6 kernel?
>
> If so, could I get some pointer to where they are?
>
Download the Denx ELDK 4.0 CD-ROM it has everything you need.
http://www.denx.de
http://www.denx.de/wiki/view/DULG/ELDKAvailability
http://www.denx.de/wiki/view/DULG/ELDKDownloadPowerPC
The install file tells you how to install the tools,
http://www.denx.de/wiki/view/DULG/ELDKInitialInstallation
for example, I use the 440EP which has an FPU, so
to install the tools (from the ELDK CD-ROM after
mounting the iso image)
./install -d /opt/eldk-4.0 ppc_4xxFP
you'll want
./install -d /opt/eldk-4.0 ppc_4xx
Read the Denx UBoot+Linux Guide (DULG), it'll help.
Regards,
Dave
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-05 14:09 UTC (permalink / raw)
To: Linus Torvalds, linuxppc-dev; +Cc: Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.64.0602262122000.22647@g5.osdl.org>
On Sun, Feb 26, Linus Torvalds wrote:
> Have I missed anything? Holler. And please keep reminding about any
> regressions since 2.6.15.
I see random memory corruption on an early G3 ibook.
Testcase is an openSuSE 10.1 installation. 2.6.15 works ok modulo 2 bugs
to get it booted at all, and the usual udev breakage.
plain 2.6.16-rc5-git7 locks up after a few packages, no ping.
Our SuSE kernel does not lockup, but ext2 shows access beyond end of
device after > 200 packages, or the rpmdb gets corrupt, or both. With reiserfs
it gets past 100 packages, then reiserfs complains about fs corruption.
plain -rc2 shows the same reiserfs corruption.
plain -rc1 dies after a few packages, it jumps to 0x0 in softirq.
I'm trying to compile the git snapshots now, which is a real challenge..
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-05 18:59 UTC (permalink / raw)
To: Linus Torvalds, linuxppc-dev; +Cc: Linux Kernel Mailing List
In-Reply-To: <20060305140932.GA17132@suse.de>
On Sun, Mar 05, Olaf Hering wrote:
> On Sun, Feb 26, Linus Torvalds wrote:
>
> > Have I missed anything? Holler. And please keep reminding about any
> > regressions since 2.6.15.
>
> I see random memory corruption on an early G3 ibook.
> Testcase is an openSuSE 10.1 installation. 2.6.15 works ok modulo 2 bugs
> to get it booted at all, and the usual udev breakage.
>
> plain 2.6.16-rc5-git7 locks up after a few packages, no ping.
> Our SuSE kernel does not lockup, but ext2 shows access beyond end of
> device after > 200 packages, or the rpmdb gets corrupt, or both. With reiserfs
> it gets past 100 packages, then reiserfs complains about fs corruption.
> plain -rc2 shows the same reiserfs corruption.
> plain -rc1 dies after a few packages, it jumps to 0x0 in softirq.
-git5 works, -git7 showed reiserfs corruption. -git6 died, jumped from
__do_softirq to 0x0, will try once again.
git5->6 has the mutex changes, but also lots of powerpc changes. Lets
see if I can narrow it down further.
The ibook has 160mb, installation is done via modular nfs
(ro,v3,rsize=32768,wsize=32768,hard,nolock,proto=tcp,addr=1.1.1.3)
I havent seen this on a B&W G3 with 256mb, nor on other ppc32 systems.
^ permalink raw reply
* Re: kmod: /sbin/modprobe char-major-4 failed
From: Antonio Di Bacco @ 2006-03-05 19:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060303141742.21257.qmail@mx1.aruba.it>
On Friday 03 March 2006 15:17, antonio.dibacco wrote:
> Why should the kernel try to load this char-major-4? What should I
> configure in the kernel to have this module not loadable but included in
> the kernel?
>
> Bye,
> Antonio.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Simply you missed modprobe!!!!
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Linus Torvalds @ 2006-03-05 20:02 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <20060305185923.GA21519@suse.de>
On Sun, 5 Mar 2006, Olaf Hering wrote:
> On Sun, Mar 05, Olaf Hering wrote:
> >
> > plain 2.6.16-rc5-git7 locks up after a few packages, no ping.
> > Our SuSE kernel does not lockup, but ext2 shows access beyond end of
> > device after > 200 packages, or the rpmdb gets corrupt, or both. With reiserfs
> > it gets past 100 packages, then reiserfs complains about fs corruption.
> > plain -rc2 shows the same reiserfs corruption.
> > plain -rc1 dies after a few packages, it jumps to 0x0 in softirq.
>
> -git5 works, -git7 showed reiserfs corruption. -git6 died, jumped from
> __do_softirq to 0x0, will try once again.
Since there are several git users in the ppc camp, one thing that always
helps is that when you test a -git snapshot, you also say what the "git
ID" was.
I'm assuming that when you say "-git5 works", you mean 2.6.15-git5.
In this case:
2.6.15-git5: 5367f2d67c7d0bf1faae90e6e7b4e2ac3c9b5e0f
2.6.15-git6: 977127174a7dff52d17faeeb4c4949a54221881f
2.6.15-git7: 05f6ece6f37f987e9de643f6f76e8fb5d5b9e014
> git5->6 has the mutex changes, but also lots of powerpc changes. Lets
> see if I can narrow it down further.
If you can try out git, the best way to proceed is
git bisect start
git bisect good 5367f2d67c7d0bf1faae90e6e7b4e2ac3c9b5e0f
git bisect bad 977127174a7dff52d17faeeb4c4949a54221881f
which should help narrow it down pretty efficiently (I'm marking -git6 as
bad, on the logic that the bug being chased is "corruption _or_ jumping to
address 0". It's much harder if you want to chase down just one bug, when
the other bug might stand in your way).
And yes, that range contains not just powerpc updates, but also PCI layer,
mutex changes, crypto and V4L/DVB. Doing just three or four bisection
trials would help narrow it down a lot (now it's 448 commits - doing three
bisctions should narrow it down into less than 60 commits and likely which
subsystem, while doing another bisection or two would get us into a few
tens of commits).
"git bisect" really is very powerful and easy to use.
Linus
^ permalink raw reply
* double fec in denx kernel 2.4
From: Antonio Di Bacco @ 2006-03-05 20:26 UTC (permalink / raw)
To: linuxppc-embedded
I saw that denx kernel has no support for double fec of MPC875. Is this true?
Then I'm going to pick up stuff from Arabella and putting into denx kernel,
is it the best way or not?
Thank you.
^ permalink raw reply
* Re: double fec in denx kernel 2.4
From: Wolfgang Denk @ 2006-03-05 20:31 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200603052126.11407.antonio.dibacco@aruba.it>
In message <200603052126.11407.antonio.dibacco@aruba.it> you wrote:
> I saw that denx kernel has no support for double fec of MPC875. Is this true?
That's true for MPC8xx in our 2.4 kernel tree.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to
be assimilated.
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-05 20:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.64.0603051147590.13139@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]
On Sun, Mar 05, Linus Torvalds wrote:
> "git bisect" really is very powerful and easy to use.
Indeed. The one "between" gi5 and git6
(93b47684f60cf25e8cefe19a21d94aa0257fdf36) is fails also. There are no
mutex changes left, so I suspect some ppc bug.
With this changeset, my first attempt ran into this deadlock, the second
attempt lead to the reiserfs corruption.
See attached 93b47684f60cf25e8cefe19a21d94aa0257fdf36.log
I'm now at 03929c76f3e5af919fb762e9882a9c286d361e7d, which fails as
well. dmesg shows this:
Adding 295332k swap on /dev/hda10. Priority:-1 extents:1 across:295332k
ReiserFS: warning: is_leaf: wrong item type for item *3.5*[-1 -1 0xffffffff DIRECT], item_len 65535, item_location 65535, free_space(entry_count) 65535
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [2 4652 0x0 SD]
ReiserFS: warning: is_leaf: wrong item type for item *3.5*[-1 -1 0xffffffff DIRECT], item_len 65535, item_location 65535, free_space(entry_count) 65535
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [2 4652 0x0 SD]
ReiserFS: warning: is_leaf: wrong item type for item *3.5*[-1 -1 0xffffffff DIRECT], item_len 65535, item_location 65535, free_space(entry_count) 65535
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [2 4652 0x0 SD]
There are only powerpc related changes left.
Its a bit time comsuming until I get to the point of where it fails,
lets see how far I get this evening.
[-- Attachment #2: 93b47684f60cf25e8cefe19a21d94aa0257fdf36.log --]
[-- Type: text/x-log, Size: 24139 bytes --]
inst-sys:~ # dmesg
device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel@redhat.com
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
raid5: measuring checksumming speed
8regs : 351.000 MB/sec
8regs_prefetch: 296.000 MB/sec
32regs : 325.000 MB/sec
32regs_prefetch: 285.000 MB/sec
raid5: using function: 8regs (351.000 MB/sec)
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid6: int32x1 58 MB/s
raid6: int32x2 88 MB/s
raid6: int32x4 110 MB/s
raid6: int32x8 105 MB/s
raid6: using algorithm int32x4 (110 MB/s)
md: raid6 personality registered for level 6
md: multipath personality registered for level -4
hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdc: packet command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
cdrom: open failed.
ReiserFS: hda11: found reiserfs format "3.6" with standard journal
ReiserFS: hda11: using ordered data mode
ReiserFS: hda11: journal params: device hda11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda11: checking transaction log (hda11)
ReiserFS: hda11: Using r5 hash to sort names
ReiserFS: hda11: warning: Created .reiserfs_priv on hda11 - reserved for xattr storage.
Adding 295332k swap on /dev/hda10. Priority:-1 extents:1 across:295332k
SysRq : Show State
sibling
task PC pid father child younger older
init S 0FEC24B4 0 1 0 2 (NOTLB)
Call Trace:
[C2D29D90] [C2D29E40] 0xc2d29e40 (unreliable)
[C2D29E50] [C000C318] __switch_to+0x5c/0x74
[C2D29E70] [C02D3B28] schedule+0x680/0x734
[C2D29EB0] [C00332D0] do_wait+0xc88/0xe94
[C2D29F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfec24b4
LR = 0xfe5ed00
ksoftirqd/0 S 00000000 0 2 1 3 (L-TLB)
Call Trace:
[C2D2BE90] [EA6713EA] 0xea6713ea (unreliable)
[C2D2BF50] [C000C318] __switch_to+0x5c/0x74
[C2D2BF70] [C02D3B28] schedule+0x680/0x734
[C2D2BFB0] [C0035D74] ksoftirqd+0x4c/0xa8
[C2D2BFC0] [C0048900] kthread+0xd4/0x110
[C2D2BFF0] [C00117C4] kernel_thread+0x44/0x60
watchdog/0 S 00000000 0 3 1 4 2 (L-TLB)
Call Trace:
[C2D2DE30] [7C00F54F] 0x7c00f54f (unreliable)
[C2D2DEF0] [C000C318] __switch_to+0x5c/0x74
[C2D2DF10] [C02D3B28] schedule+0x680/0x734
[C2D2DF50] [C02D4618] schedule_timeout+0x98/0xc8
[C2D2DF90] [C003B374] msleep_interruptible+0x38/0x6c
[C2D2DFA0] [C0058068] watchdog+0x44/0x84
[C2D2DFC0] [C0048900] kthread+0xd4/0x110
[C2D2DFF0] [C00117C4] kernel_thread+0x44/0x60
events/0 S 00000000 0 4 1 5 3 (L-TLB)
Call Trace:
[C2787E20] [00000001] 0x1 (unreliable)
[C2787EE0] [C000C318] __switch_to+0x5c/0x74
[C2787F00] [C02D3B28] schedule+0x680/0x734
[C2787F40] [C0043A1C] worker_thread+0xdc/0x224
[C2787FC0] [C0048900] kthread+0xd4/0x110
[C2787FF0] [C00117C4] kernel_thread+0x44/0x60
khelper S 00000000 0 5 1 6 4 (L-TLB)
Call Trace:
[C2CE1E20] [C0043940] worker_thread+0x0/0x224 (unreliable)
[C2CE1EE0] [C000C318] __switch_to+0x5c/0x74
[C2CE1F00] [C02D3B28] schedule+0x680/0x734
[C2CE1F40] [C0043A1C] worker_thread+0xdc/0x224
[C2CE1FC0] [C0048900] kthread+0xd4/0x110
[C2CE1FF0] [C00117C4] kernel_thread+0x44/0x60
kthread S 00000000 0 6 1 24 73 5 (L-TLB)
Call Trace:
[C2789E20] [0000000A] 0xa (unreliable)
[C2789EE0] [C000C318] __switch_to+0x5c/0x74
[C2789F00] [C02D3B28] schedule+0x680/0x734
[C2789F40] [C0043A1C] worker_thread+0xdc/0x224
[C2789FC0] [C0048900] kthread+0xd4/0x110
[C2789FF0] [C00117C4] kernel_thread+0x44/0x60
kblockd/0 S 00000000 0 24 6 28 (L-TLB)
Call Trace:
[C9B41E20] [C04798C0] ide_hwifs+0x0/0x41c0 (unreliable)
[C9B41EE0] [C000C318] __switch_to+0x5c/0x74
[C9B41F00] [C02D3B28] schedule+0x680/0x734
[C9B41F40] [C0043A1C] worker_thread+0xdc/0x224
[C9B41FC0] [C0048900] kthread+0xd4/0x110
[C9B41FF0] [C00117C4] kernel_thread+0x44/0x60
khubd S 00000000 0 28 6 71 24 (L-TLB)
Call Trace:
[C9B4FE10] [C0224D98] urb_destroy+0x10/0x20 (unreliable)
[C9B4FED0] [C000C318] __switch_to+0x5c/0x74
[C9B4FEF0] [C02D3B28] schedule+0x680/0x734
[C9B4FF30] [C022223C] hub_thread+0xb78/0xc08
[C9B4FFC0] [C0048900] kthread+0xd4/0x110
[C9B4FFF0] [C00117C4] kernel_thread+0x44/0x60
pdflush S 00000000 0 71 6 72 28 (L-TLB)
Call Trace:
[C9B6BE60] [C003ABD8] process_timeout+0x0/0x20 (unreliable)
[C9B6BF20] [C000C318] __switch_to+0x5c/0x74
[C9B6BF40] [C02D3B28] schedule+0x680/0x734
[C9B6BF80] [C0060E58] pdflush+0xc0/0x218
[C9B6BFC0] [C0048900] kthread+0xd4/0x110
[C9B6BFF0] [C00117C4] kernel_thread+0x44/0x60
pdflush D 00000000 0 72 6 74 71 (L-TLB)
Call Trace:
[C9B65BF0] [000003FA] 0x3fa (unreliable)
[C9B65CB0] [C000C318] __switch_to+0x5c/0x74
[C9B65CD0] [C02D3B28] schedule+0x680/0x734
[C9B65D10] [C02D326C] __down+0x64/0xd0
[C9B65D70] [C00F896C] flush_commit_list+0x17c/0x7c4
[C9B65DB0] [C00F8900] flush_commit_list+0x110/0x7c4
[C9B65DF0] [C00FC9C4] do_journal_end+0xe74/0xec0
[C9B65E50] [C00FCA98] journal_end_sync+0x88/0x9c
[C9B65E70] [C00E5FBC] reiserfs_sync_fs+0x4c/0x88
[C9B65EB0] [C00E600C] reiserfs_write_super+0x14/0x24
[C9B65EC0] [C0089394] sync_supers+0x104/0x1c4
[C9B65EE0] [C00602D8] wb_kupdate+0x54/0x16c
[C9B65F80] [C0060EBC] pdflush+0x124/0x218
[C9B65FC0] [C0048900] kthread+0xd4/0x110
[C9B65FF0] [C00117C4] kernel_thread+0x44/0x60
aio/0 S 00000000 0 74 6 283 72 (L-TLB)
Call Trace:
[C9B49E20] [C060C000] 0xc060c000 (unreliable)
[C9B49EE0] [C000C318] __switch_to+0x5c/0x74
[C9B49F00] [C02D3B28] schedule+0x680/0x734
[C9B49F40] [C0043A1C] worker_thread+0xdc/0x224
[C9B49FC0] [C0048900] kthread+0xd4/0x110
[C9B49FF0] [C00117C4] kernel_thread+0x44/0x60
kswapd0 S 00000000 0 73 1 383 6 (L-TLB)
Call Trace:
[C9B67E60] [C02D507C] _spin_unlock_irqrestore+0x18/0x30 (unreliable)
[C9B67F20] [C000C318] __switch_to+0x5c/0x74
[C9B67F40] [C02D3B28] schedule+0x680/0x734
[C9B67F80] [C0064604] kswapd+0xc8/0xec
[C9B67FF0] [C00117C4] kernel_thread+0x44/0x60
cqueue/0 S 00000000 0 283 6 284 74 (L-TLB)
Call Trace:
[C9BEDE20] [C060C000] 0xc060c000 (unreliable)
[C9BEDEE0] [C000C318] __switch_to+0x5c/0x74
[C9BEDF00] [C02D3B28] schedule+0x680/0x734
[C9BEDF40] [C0043A1C] worker_thread+0xdc/0x224
[C9BEDFC0] [C0048900] kthread+0xd4/0x110
[C9BEDFF0] [C00117C4] kernel_thread+0x44/0x60
kseriod S 00000000 0 284 6 1064 283 (L-TLB)
Call Trace:
[C9BF7E40] [C00CB664] sysfs_new_dirent+0x2c/0x94 (unreliable)
[C9BF7F00] [C000C318] __switch_to+0x5c/0x74
[C9BF7F20] [C02D3B28] schedule+0x680/0x734
[C9BF7F60] [C01E791C] serio_thread+0x2e8/0x33c
[C9BF7FC0] [C0048900] kthread+0xd4/0x110
[C9BF7FF0] [C00117C4] kernel_thread+0x44/0x60
udevd S 0FF626D4 0 383 1 947 73 (NOTLB)
Call Trace:
[C2D69CE0] [0000000A] 0xa (unreliable)
[C2D69DA0] [C000C318] __switch_to+0x5c/0x74
[C2D69DC0] [C02D3B28] schedule+0x680/0x734
[C2D69E00] [C02D45AC] schedule_timeout+0x2c/0xc8
[C2D69E40] [C0097E68] do_select+0x328/0x384
[C2D69EC0] [C00981C0] sys_select+0x2fc/0x4dc
[C2D69F10] [C0004D98] ppc_select+0xfc/0x118
[C2D69F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff626d4
LR = 0x1000317c
bash S 0FE372A8 0 947 1 1061 383 (NOTLB)
Call Trace:
[C9E1FCD0] [08D4B305] 0x8d4b305 (unreliable)
[C9E1FD90] [C000C318] __switch_to+0x5c/0x74
[C9E1FDB0] [C02D3B28] schedule+0x680/0x734
[C9E1FDF0] [C02D45AC] schedule_timeout+0x2c/0xc8
[C9E1FE30] [C01D63E0] read_chan+0x368/0x814
[C9E1FEC0] [C01D2674] tty_read+0x8c/0xdc
[C9E1FEF0] [C008002C] vfs_read+0xec/0x1c4
[C9E1FF10] [C00804CC] sys_read+0x4c/0x94
[C9E1FF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfe372a8
LR = 0xffc96e4
dhcpcd S 07F33CF0 0 1061 1 1063 947 (NOTLB)
Call Trace:
[C258FDB0] [C00A236C] mntput_no_expire+0x2c/0xc4 (unreliable)
[C258FE70] [C000C318] __switch_to+0x5c/0x74
[C258FE90] [C02D3B28] schedule+0x680/0x734
[C258FED0] [C02D4618] schedule_timeout+0x98/0xc8
[C258FF10] [C003B5DC] sys_nanosleep+0x128/0x260
[C258FF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0x7f33cf0
LR = 0x7f33aa4
portmap S 07F111E0 0 1063 1 1065 1061 (NOTLB)
Call Trace:
[C2595D90] [C025C698] move_addr_to_kernel+0x90/0xc4 (unreliable)
[C2595E50] [C000C318] __switch_to+0x5c/0x74
[C2595E70] [C02D3B28] schedule+0x680/0x734
[C2595EB0] [C02D45AC] schedule_timeout+0x2c/0xc8
[C2595EF0] [C0098614] sys_poll+0x274/0x360
[C2595F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0x7f111e0
LR = 0x7f1119c
rpciod/0 S 00000000 0 1064 6 3348 284 (L-TLB)
Call Trace:
[C258BE20] [C02D507C] _spin_unlock_irqrestore+0x18/0x30 (unreliable)
[C258BEE0] [C000C318] __switch_to+0x5c/0x74
[C258BF00] [C02D3B28] schedule+0x680/0x734
[C258BF40] [C0043A1C] worker_thread+0xdc/0x224
[C258BFC0] [C0048900] kthread+0xd4/0x110
[C258BFF0] [C00117C4] kernel_thread+0x44/0x60
lockd S 00000000 0 1065 1 1066 1063 (L-TLB)
Call Trace:
[C2591E00] [C007AA64] cache_free_debugcheck+0x214/0x22c (unreliable)
[C2591EC0] [C000C318] __switch_to+0x5c/0x74
[C2591EE0] [C02D3B28] schedule+0x680/0x734
[C2591F20] [C02D45AC] schedule_timeout+0x2c/0xc8
[C2591F60] [CB18F0D4] svc_recv+0x300/0x530 [sunrpc]
[C2591FD0] [CB152924] lockd+0x168/0x280 [lockd]
[C2591FF0] [C00117C4] kernel_thread+0x44/0x60
loop0 S 00000000 0 1066 1 1084 1065 (L-TLB)
Call Trace:
[C2DADE10] [C2DADE60] 0xc2dade60 (unreliable)
[C2DADED0] [C000C318] __switch_to+0x5c/0x74
[C2DADEF0] [C02D3B28] schedule+0x680/0x734
[C2DADF30] [C02D3370] __down_interruptible+0x98/0x10c
[C2DADF90] [CB104630] loop_thread+0xac/0x468 [loop]
[C2DADFF0] [C00117C4] kernel_thread+0x44/0x60
bash R running 0 1084 1 1087 1066 (NOTLB)
bash S 0FE372A8 0 1087 1 1090 1084 (NOTLB)
Call Trace:
[C887BCD0] [08BA8785] 0x8ba8785 (unreliable)
[C887BD90] [C000C318] __switch_to+0x5c/0x74
[C887BDB0] [C02D3B28] schedule+0x680/0x734
[C887BDF0] [C02D45AC] schedule_timeout+0x2c/0xc8
[C887BE30] [C01D63E0] read_chan+0x368/0x814
[C887BEC0] [C01D2674] tty_read+0x8c/0xdc
[C887BEF0] [C008002C] vfs_read+0xec/0x1c4
[C887BF10] [C00804CC] sys_read+0x4c/0x94
[C887BF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfe372a8
LR = 0xffc96e4
bash S 0FE372A8 0 1090 1 1093 1087 (NOTLB)
Call Trace:
[C88D1CD0] [08B8F785] 0x8b8f785 (unreliable)
[C88D1D90] [C000C318] __switch_to+0x5c/0x74
[C88D1DB0] [C02D3B28] schedule+0x680/0x734
[C88D1DF0] [C02D45AC] schedule_timeout+0x2c/0xc8
[C88D1E30] [C01D63E0] read_chan+0x368/0x814
[C88D1EC0] [C01D2674] tty_read+0x8c/0xdc
[C88D1EF0] [C008002C] vfs_read+0xec/0x1c4
[C88D1F10] [C00804CC] sys_read+0x4c/0x94
[C88D1F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfe372a8
LR = 0xffc96e4
inst_setup S 0FE114B4 0 1093 1 1209 1096 1090 (NOTLB)
Call Trace:
[C8921D90] [C006A390] __handle_mm_fault+0x1214/0x12cc (unreliable)
[C8921E50] [C000C318] __switch_to+0x5c/0x74
[C8921E70] [C02D3B28] schedule+0x680/0x734
[C8921EB0] [C00332D0] do_wait+0xc88/0xe94
[C8921F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfe114b4
LR = 0x100324e8
showconsole X 0FEFE178 0 1096 1 1107 1093 (L-TLB)
Call Trace:
[C8B73DD0] [C005EED8] __free_pages+0x74/0x194 (unreliable)
[C8B73E90] [C000C318] __switch_to+0x5c/0x74
[C8B73EB0] [C02D3B28] schedule+0x680/0x734
[C8B73EF0] [C0034010] do_exit+0xa8c/0xb18
[C8B73F20] [C0034138] sys_exit_group+0x0/0x8
[C8B73F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfefe178
LR = 0xfefe148
dbus-daemon S 0FC711E0 0 1107 1 1109 1096 (NOTLB)
Call Trace:
[C80E7D90] [C025ACD8] sock_writev+0x90/0xc0 (unreliable)
[C80E7E50] [C000C318] __switch_to+0x5c/0x74
[C80E7E70] [C02D3B28] schedule+0x680/0x734
[C80E7EB0] [C02D45AC] schedule_timeout+0x2c/0xc8
[C80E7EF0] [C0098614] sys_poll+0x274/0x360
[C80E7F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfc711e0
LR = 0xfc7119c
hald S 0FC611E0 0 1109 1 1125 1162 1107 (NOTLB)
Call Trace:
[C83FBD90] [C015FE70] _atomic_dec_and_lock+0x44/0x60 (unreliable)
[C83FBE50] [C000C318] __switch_to+0x5c/0x74
[C83FBE70] [C02D3B28] schedule+0x680/0x734
[C83FBEB0] [C02D4618] schedule_timeout+0x98/0xc8
[C83FBEF0] [C0098614] sys_poll+0x274/0x360
[C83FBF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfc611e0
LR = 0xfc6119c
hald-addon-st S 0FE76CF0 0 1125 1109 (NOTLB)
Call Trace:
[C7EFBDB0] [C035D7B8] xtime_lock+0x4/0x14 (unreliable)
[C7EFBE70] [C000C318] __switch_to+0x5c/0x74
[C7EFBE90] [C02D3B28] schedule+0x680/0x734
[C7EFBED0] [C02D4618] schedule_timeout+0x98/0xc8
[C7EFBF10] [C003B5DC] sys_nanosleep+0x128/0x260
[C7EFBF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfe76cf0
LR = 0xfe76aa4
syslogd.bin S 07F626D4 0 1162 1 1167 1109 (NOTLB)
Call Trace:
[C63CFCE0] [C02CD768] unix_dgram_recvmsg+0x218/0x264 (unreliable)
[C63CFDA0] [C000C318] __switch_to+0x5c/0x74
[C63CFDC0] [C02D3B28] schedule+0x680/0x734
[C63CFE00] [C02D45AC] schedule_timeout+0x2c/0xc8
[C63CFE40] [C0097E68] do_select+0x328/0x384
[C63CFEC0] [C00981C0] sys_select+0x2fc/0x4dc
[C63CFF10] [C0004D98] ppc_select+0xfc/0x118
[C63CFF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0x7f626d4
LR = 0x8007490
klogd R running 0 1167 1 1199 1162 (NOTLB)
sshd S 07A9C6D4 0 1199 1 1893 2167 1167 (NOTLB)
Call Trace:
[C5DBDCE0] [C002B43C] __wake_up_common+0x40/0x94 (unreliable)
[C5DBDDA0] [C000C318] __switch_to+0x5c/0x74
[C5DBDDC0] [C02D3B28] schedule+0x680/0x734
[C5DBDE00] [C02D45AC] schedule_timeout+0x2c/0xc8
[C5DBDE40] [C0097E68] do_select+0x328/0x384
[C5DBDEC0] [C00981C0] sys_select+0x2fc/0x4dc
[C5DBDF10] [C0004D98] ppc_select+0xfc/0x118
[C5DBDF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0x7a9c6d4
LR = 0x800ff28
yast S 0FE114B4 0 1209 1093 2279 (NOTLB)
Call Trace:
[C5B11D90] [C006A390] __handle_mm_fault+0x1214/0x12cc (unreliable)
[C5B11E50] [C000C318] __switch_to+0x5c/0x74
[C5B11E70] [C02D3B28] schedule+0x680/0x734
[C5B11EB0] [C00332D0] do_wait+0xc88/0xe94
[C5B11F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfe114b4
LR = 0x100324e8
sshd S 07A9C6D4 0 1893 1199 2055 (NOTLB)
Call Trace:
[C5E93CE0] [C0010C5C] ret_from_except+0x0/0x1c (unreliable)
--- Exception: c5e93da0 at __switch_to+0x5c/0x74
LR = 0xc5e93da0
[C5E93DA0] [C000C318] __switch_to+0x5c/0x74 (unreliable)
[C5E93DC0] [C02D3B28] schedule+0x680/0x734
[C5E93E00] [C02D45AC] schedule_timeout+0x2c/0xc8
[C5E93E40] [C0097E68] do_select+0x328/0x384
[C5E93EC0] [C00981C0] sys_select+0x2fc/0x4dc
[C5E93F10] [C0004D98] ppc_select+0xfc/0x118
[C5E93F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0x7a9c6d4
LR = 0x801675c
bash S 0FE114B4 0 2055 1893 2113 (NOTLB)
Call Trace:
[C5F2FD90] [C002BCC4] __wake_up+0x4c/0x60 (unreliable)
[C5F2FE50] [C000C318] __switch_to+0x5c/0x74
[C5F2FE70] [C02D3B28] schedule+0x680/0x734
[C5F2FEB0] [C00332D0] do_wait+0xc88/0xe94
[C5F2FF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfe114b4
LR = 0x100324e8
tail S 0FF33CF0 0 2113 2055 (NOTLB)
Call Trace:
[C5535DB0] [C00A236C] mntput_no_expire+0x2c/0xc4 (unreliable)
[C5535E70] [C000C318] __switch_to+0x5c/0x74
[C5535E90] [C02D3B28] schedule+0x680/0x734
[C5535ED0] [C02D4618] schedule_timeout+0x98/0xc8
[C5535F10] [C003B5DC] sys_nanosleep+0x128/0x260
[C5535F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff33cf0
LR = 0x10005e4c
gzip X 0FF34178 0 2167 1 2865 1199 (L-TLB)
Call Trace:
[C5593DD0] [00000001] 0x1 (unreliable)
[C5593E90] [C000C318] __switch_to+0x5c/0x74
[C5593EB0] [C02D3B28] schedule+0x680/0x734
[C5593EF0] [C0034010] do_exit+0xa8c/0xb18
[C5593F20] [C0034138] sys_exit_group+0x0/0x8
[C5593F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff34178
LR = 0xff34148
YaST2.call S 0FE114B4 0 2279 1209 2844 (NOTLB)
Call Trace:
[C5507D90] [C006A390] __handle_mm_fault+0x1214/0x12cc (unreliable)
[C5507E50] [C000C318] __switch_to+0x5c/0x74
[C5507E70] [C02D3B28] schedule+0x680/0x734
[C5507EB0] [C00332D0] do_wait+0xc88/0xe94
[C5507F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfe114b4
LR = 0x100324e8
y2base S 0F3242E4 0 2844 2279 3387 2845 (NOTLB)
Call Trace:
[C4A81D00] [00009032] 0x9032 (unreliable)
[C4A81DC0] [C000C318] __switch_to+0x5c/0x74
[C4A81DE0] [C02D3B28] schedule+0x680/0x734
[C4A81E20] [C008F9B4] pipe_wait+0x88/0xdc
[C4A81E80] [C0090294] pipe_readv+0x2b8/0x360
[C4A81ED0] [C009035C] pipe_read+0x20/0x30
[C4A81EF0] [C008002C] vfs_read+0xec/0x1c4
[C4A81F10] [C00804CC] sys_read+0x4c/0x94
[C4A81F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xf3242e4
LR = 0xf3242cc
y2base S 0F32D720 0 2845 2279 2844 (NOTLB)
Call Trace:
[C7F7FCE0] [5A2CF071] 0x5a2cf071 (unreliable)
[C7F7FDA0] [C000C318] __switch_to+0x5c/0x74
[C7F7FDC0] [C02D3B28] schedule+0x680/0x734
[C7F7FE00] [C02D4618] schedule_timeout+0x98/0xc8
[C7F7FE40] [C0097E68] do_select+0x328/0x384
[C7F7FEC0] [C00981C0] sys_select+0x2fc/0x4dc
[C7F7FF10] [C0004D98] ppc_select+0xfc/0x118
[C7F7FF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xf32d720
LR = 0xf32d700
gzip X 0FF34178 0 2865 1 2893 2167 (L-TLB)
Call Trace:
[C76DFDD0] [00000001] 0x1 (unreliable)
[C76DFE90] [C000C318] __switch_to+0x5c/0x74
[C76DFEB0] [C02D3B28] schedule+0x680/0x734
[C76DFEF0] [C0034010] do_exit+0xa8c/0xb18
[C76DFF20] [C0034138] sys_exit_group+0x0/0x8
[C76DFF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff34178
LR = 0xff34148
gzip X 0FF34178 0 2893 1 2913 2865 (L-TLB)
Call Trace:
[C726FDD0] [00000001] 0x1 (unreliable)
[C726FE90] [C000C318] __switch_to+0x5c/0x74
[C726FEB0] [C02D3B28] schedule+0x680/0x734
[C726FEF0] [C0034010] do_exit+0xa8c/0xb18
[C726FF20] [C0034138] sys_exit_group+0x0/0x8
[C726FF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff34178
LR = 0xff34148
gzip X 0FF34178 0 2913 1 3120 2893 (L-TLB)
Call Trace:
[C7327DD0] [C7327E80] 0xc7327e80 (unreliable)
[C7327E90] [C000C318] __switch_to+0x5c/0x74
[C7327EB0] [C02D3B28] schedule+0x680/0x734
[C7327EF0] [C0034010] do_exit+0xa8c/0xb18
[C7327F20] [C0034138] sys_exit_group+0x0/0x8
[C7327F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff34178
LR = 0xff34148
gzip X 0FF34178 0 3120 1 3241 2913 (L-TLB)
Call Trace:
[C443FDD0] [C005EED8] __free_pages+0x74/0x194 (unreliable)
[C443FE90] [C000C318] __switch_to+0x5c/0x74
[C443FEB0] [C02D3B28] schedule+0x680/0x734
[C443FEF0] [C0034010] do_exit+0xa8c/0xb18
[C443FF20] [C0034138] sys_exit_group+0x0/0x8
[C443FF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff34178
LR = 0xff34148
gzip X 0FF34178 0 3241 1 3120 (L-TLB)
Call Trace:
[C870FDD0] [C005EED8] __free_pages+0x74/0x194 (unreliable)
[C870FE90] [C000C318] __switch_to+0x5c/0x74
[C870FEB0] [C02D3B28] schedule+0x680/0x734
[C870FEF0] [C0034010] do_exit+0xa8c/0xb18
[C870FF20] [C0034138] sys_exit_group+0x0/0x8
[C870FF40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff34178
LR = 0xff34148
reiserfs/0 D 00000000 0 3348 6 1064 (L-TLB)
Call Trace:
[C71A3D20] [C01525D8] submit_bio+0xe0/0xf4 (unreliable)
[C71A3DE0] [C000C318] __switch_to+0x5c/0x74
[C71A3E00] [C02D3B28] schedule+0x680/0x734
[C71A3E40] [C02D326C] __down+0x64/0xd0
[C71A3EA0] [C00F896C] flush_commit_list+0x17c/0x7c4
[C71A3EE0] [C00F8900] flush_commit_list+0x110/0x7c4
[C71A3F20] [C00FD8A8] flush_async_commits+0x3c/0xa0
[C71A3F40] [C0043AD8] worker_thread+0x198/0x224
[C71A3FC0] [C0048900] kthread+0xd4/0x110
[C71A3FF0] [C00117C4] kernel_thread+0x44/0x60
rpm D 0FAA793C 0 3387 2844 (NOTLB)
Call Trace:
[C5BC1B40] [C280C7DC] 0xc280c7dc (unreliable)
[C5BC1C00] [C000C318] __switch_to+0x5c/0x74
[C5BC1C20] [C02D3B28] schedule+0x680/0x734
[C5BC1C60] [C02D3CF8] io_schedule+0x30/0x60
[C5BC1C80] [C0082CBC] sync_buffer+0x50/0x64
[C5BC1C90] [C02D4958] __wait_on_bit+0x60/0xb0
[C5BC1CB0] [C02D4A24] out_of_line_wait_on_bit+0x7c/0x90
[C5BC1D20] [C0082B84] __wait_on_buffer+0x2c/0x3c
[C5BC1D30] [C00F86A0] write_ordered_buffers+0x248/0x2a4
[C5BC1DE0] [C00F8A20] flush_commit_list+0x230/0x7c4
[C5BC1E20] [C00FC9C4] do_journal_end+0xe74/0xec0
[C5BC1E80] [C00FCA98] journal_end_sync+0x88/0x9c
[C5BC1EA0] [C00FD54C] reiserfs_commit_for_inode+0x140/0x1c8
[C5BC1F00] [C00DD2B8] reiserfs_sync_file+0x44/0x90
[C5BC1F20] [C008269C] do_fsync+0xb0/0x128
[C5BC1F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfaa793c
LR = 0xfee6110
inst-sys:~ # dmesg |o
device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel@redhat.com
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
raid5: measuring checksumming speed
8regs : 351.000 MB/sec
8regs_prefetch: 296.000 MB/sec
32regs : 325.000 MB/sec
32regs_prefetch: 285.000 MB/sec
raid5: using function: 8regs (351.000 MB/sec)
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid6: int32x1 58 MB/s
raid6: int32x2 88 MB/s
raid6: int32x4 110 MB/s
raid6: int32x8 105 MB/s
raid6: using algorithm int32x4 (110 MB/s)
md: raid6 personality registered for level 6
md: multipath personality registered for level -4
hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdc: packet command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
cdrom: open failed.
ReiserFS: hda11: found reiserfs format "3.6" with standard journal
ReiserFS: hda11: using ordered data mode
ReiserFS: hda11: journal params: device hda11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda11: checking transaction log (hda11)
ReiserFS: hda11: Using r5 hash to sort names
ReiserFS: hda11: warning: Created .reiserfs_priv on hda11 - reserved for xattr storage.
Adding 295332k swap on /dev/hda10. Priority:-1 extents:1 across:295332k
SysRq : Show State
sibling
task PC pid father child younger older
init S 0FEC24B4 0 1 0 2 (NOTLB)
Call Trace:
[C2D29D90] [C2D29E40] 0xc2d29e40 (unreliable)
[C2D29E50] [C000C318] __switch_to+0x5c/0x74
[C2D29E70] [C02D3B28] schedule+0x680/0x734
[C2D29EB0] [C00332D0] do_wait+0xc88/0xe94
[C2D29F40] [C001052C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xfec24b4
LR = 0xfe5ed00
ksoftirqd/0 S 00000000 0 2 1 3 (L-TLB)
Call Trace:
[C2D2BE90] [EA6713EA] 0xea6713ea (unreliable)
[C2D2BF50] [C000C318] __switch_to+0x5c/0x74
[C2D2BF70] [C02D3B28] schedule+0x680/0x734
[C2D2BFB0] [C0035D74] ksoftirqd+0x4c/0xa8
[C2D2BFC0] [C0048900] kthread+0xd4/0x110
[C2D2BFF0] [C00117C4] kernel_thread+0x44/0x60
watchdog/0 S 00000000 0 3 1 4 2 (L-TLB)
inst-sys:~ # ( ps faxwwwwwwww ; dmesg) > 93b47684f60cf25e8cefe19a21d94aa0257fdf36.log
inst-sys:~ # scp 93b47684f60cf25e8cefe19a21d94aa0257fdf36.log olaf@1.1.1.3:
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Paul Mackerras @ 2006-03-05 21:50 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <20060305204231.GA22002@suse.de>
Olaf Hering writes:
> I'm now at 03929c76f3e5af919fb762e9882a9c286d361e7d, which fails as
> well. dmesg shows this:
The range from git5 to there includes David Woodhouse's syscall
entry/exit revamp (401d1f029bebb7153ca704997772113dc36d9527) and the
follow-ons which fix it for 32-bit:
9687c587596b54a77f08620595f5686ea35eed97
623703f620453c798b6fa3eb79ad8ea27bfd302a
There are also commits from Ben H that change the way we parse
addresses from the OF device tree. If you can bisect a bit further
that would be good, although you may strike problems between the 401d
and 6237 commits I mentioned above.
It would be interesting to take 401d and then apply 9687 and 6237
directly on top of it and try that, and if it fails, then try
1cd8e506209223ed10da805d99be55e268f4023c (the parent of 401d).
Paul.
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-05 22:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <17419.23860.883220.80199@cargo.ozlabs.ibm.com>
On Mon, Mar 06, Paul Mackeras wrote:
> Olaf Hering writes:
>
> > I'm now at 03929c76f3e5af919fb762e9882a9c286d361e7d, which fails as
> > well. dmesg shows this:
>
> The range from git5 to there includes David Woodhouse's syscall
> entry/exit revamp (401d1f029bebb7153ca704997772113dc36d9527) and the
> follow-ons which fix it for 32-bit:
>
> 9687c587596b54a77f08620595f5686ea35eed97
> 623703f620453c798b6fa3eb79ad8ea27bfd302a
>
> There are also commits from Ben H that change the way we parse
> addresses from the OF device tree. If you can bisect a bit further
> that would be good, although you may strike problems between the 401d
> and 6237 commits I mentioned above.
I will check this tomorrow.
quick update:
d4e4b3520c4df46cf1d15a56379a6fa57e267b7d, locks up, tried two times
404849bbd2bfd62e05b36f4753f6e1af6050a824 + 3 buildfixes:
31df1678d7732b94178a6e457ed6666e4431212f
8dacaedf04467e32c50148751a96150e73323cdc
d2dd482bc17c3bc240045f80a7c4b4d5cea5e29c
This one has the syscall changes, but not the two fixes you mentioned.
It gets far, but at the point where it locks up with the d4eb, it
crashes in run_timer_softirq, branched to 0x1f4. Maybe its the result of
the missing fixes. Will continue tomorrow.
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-05 22:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <20060305222202.GA22450@suse.de>
On Sun, Mar 05, Olaf Hering wrote:
> 404849bbd2bfd62e05b36f4753f6e1af6050a824 + 3 buildfixes:
>
> 31df1678d7732b94178a6e457ed6666e4431212f
> 8dacaedf04467e32c50148751a96150e73323cdc
> d2dd482bc17c3bc240045f80a7c4b4d5cea5e29c
>
>
> This one has the syscall changes, but not the two fixes you mentioned.
> It gets far, but at the point where it locks up with the d4eb, it
> crashes in run_timer_softirq, branched to 0x1f4. Maybe its the result of
> the missing fixes. Will continue tomorrow.
Another try with that version, now I see the corruption before the
package where it locked up before (glibc-locale, rather large).
Will backout the syscall change and try again with 404849bbd2bfd62e05b36f4753f6e1af6050a824.
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Michael Ellerman @ 2006-03-06 1:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olaf Hering
In-Reply-To: <20060304191026.GA9815@suse.de>
[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]
On Sun, 5 Mar 2006 06:10, Olaf Hering wrote:
> Do not call prom exit prom_panic. It clears the screen and the exit message
> is lost. On some (or all?) pmacs it causes another crash when OF tries to
> print the date and time in its banner.
>
> Signed-off-by: Olaf Hering <olh@suse.de>
>
> arch/powerpc/kernel/prom_init.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
> ===================================================================
> --- linux-2.6.16-rc5-olh.orig/arch/powerpc/kernel/prom_init.c
> +++ linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
> @@ -398,7 +398,9 @@ static void __init __attribute__((noretu
> #endif
> prom_print(reason);
> /* ToDo: should put up an SRC here on p/iSeries */
> - call_prom("exit", 0, 0);
> + /* Do not call exit because it clears the screen on pmac
> + * it also causes some sort of double-fault on early pmacs */
> + asm("trap\n");
>
> for (;;) /* should never get here */
> ;
I don't think I like it, on IBM firmware it takes us from this:
Elapsed time since release of system processors: 26005 mins 51 secs
zImage starting: loaded at 0x00400000 (sp: 0x01a1ffe0)
Allocating 0x7edc50 bytes for kernel ...
OF version = 'IBM,SF230_126'
gunzipping (0x1c00000 <- 0x407000:0x6a04e4)...done 0x766880 bytes
OF stdout device is: /vdevice/vty@30000000
Error: You can't boot a kdump kernel from OF!
EXIT called ok
0 >
To this:
Elapsed time since release of system processors: 25995 mins 56 secs
zImage starting: loaded at 0x00400000 (sp: 0x01a1ffe0)
Allocating 0x7edc50 bytes for kernel ...
OF version = 'IBM,SF230_126'
gunzipping (0x1c00000 <- 0x407000:0x6a044b)...done 0x766880 bytes
OF stdout device is: /vdevice/vty@30000000
Error: You can't boot a kdump kernel from OF!
DEFAULT CATCH!, exception-handler=fff00700
at %SRR0: 00000000020eaf78 %SRR1: 8000000000023002
Open Firmware exception handler entered from non-OF code
Client's Fix Pt Regs:
00 00000000020eaf78 0000000001a1fe90 00000000023681d0 0000000000000002
04 0000000044000024 0000000000000000 0000000000000000 0000000002063e1e
08 0000000000000000 0000000001a1fc9c 0000000000003002 0000000000003002
0c 2000000000000000 0000000000000000 0000000000000000 0000000000000000
10 0000000000000000 0000000000000000 0000000000000000 0000000000000000
14 0000000000c00000 0000000000000008 0000000000000000 0000000000000000
18 0000000000000000 0000000000000000 0000000000000000 0000000000c39a48
1c c000000002453cc8 0000000002108938 0000000000000000 fffffffffffffffd
Special Regs:
%IV: 00000700 %CR: 44000022 %XER: 00000000 %DSISR: 00000000
%SRR0: 00000000020eaf78 %SRR1: 8000000000023002
%LR: 00000000020eaf78 %CTR: 0000000000000000
%DAR: 0000000000000000
Virtual PID = 0
PFW: Unable to send error log!
ok
0 >
cheers
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: linux DMA capabilities in MV64460
From: Phil Nitschke @ 2006-03-06 4:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051220010136.GA31165@mag.az.mvista.com>
>>>>> "MAG" == Mark A Greer <mgreer@mvista.com> writes:
MAG> On Tue, Dec 20, 2005 at 10:49:58AM +1030, Phil Nitschke wrote:
>> ... if I wanted to suck the data into main memory using the mv64460
>> IDMA controller (assuming the device couldn't initiate its own
>> burst writes), is there a standard kernel interface to allow me to
>> do this?
MAG> Yes. You would make a "dma ctlr driver" for the dma ctlr(s). I
MAG> don't know what the best example would be but hopefully someone
MAG> else has a suggestion.
I'm following up to a thread started in December last year. The thread
was talking about this device:
http://www.marvell.com/products/communication/discoveryIII/index.jsp
http://www.marvell.com/products/communication/Discovery%20MV64460%20FINAL.pdf
Currently I've found the linux kernel has the following files relevant
to this hardware (2.6.15 kernel):
./arch/ppc/syslib/mv64360_pic.c
./arch/ppc/syslib/mv64x60.c
./arch/ppc/syslib/mv64x60_dbg.c
./arch/ppc/syslib/mv64x60_win.c
./drivers/char/watchdog/mv64x60_wdt.c
./drivers/i2c/busses/i2c-mv64xxx.c
./drivers/net/mv643xx_eth.c
I'm now looking seriously (and reluctantly!) at writing a DMA Controller
Driver to supplement these functions, and I've started the process of
getting an NDA from Marvell, so I can get their User Manual (and errata!).
Can someone point me in the right direction to get me started? I need
to come up the learning curve to find out where to start.
How is a DMA controlled (from a device driver writer's perspective) when
a third-party (i.e. in the bridge) DMA controller needs to do the work
to get the data from a PCI Target into main memory?
What kernel API should be provided by the DMA Controller Driver?
Any documentation, examples, similar device drivers, etc, would be
appreciated. TIA,
--
Phil
^ permalink raw reply
* Re: PQ2FADS_ZU: u-boot-1.1.4, eldk.3.1.1, linux-2.4.25 boots problem
From: KokHow Teh @ 2006-03-06 5:05 UTC (permalink / raw)
To: linuxppc-embedded
On Fri, 24 Feb 2006 18:03:21 +0800
"KokHow Teh" <KokHow.Teh@marconi.com> wrote:
>> Hi;
>> I use the above software, apply
linuxppc-2005-03-06-2006-02-15.patch
>> from http://mpc8260sar.sourceforge.net/, `make PQ2FADS_config`, not
using
>> devfs and never manage to boot the kernel:
>>
>> u-boot> printenv
>> ramboot=setenv bootargs root=/dev/ram rw;tftp $ramdiskaddr
$ramdiskfile;tftp $loadaddr $bootfile
>> ;bootm $loadaddr $ramdiskaddr
>> bootdelay=10
>> baudrate=115200
>> ethaddr=08:00:3E:33:44:56
>> ipaddr=147.128.28.44
>> serverip=147.128.28.42
>> rootpath="/fadsroot"
>> gatewayip=147.128.28.1
>> netmask=255.255.254.0
>> hostname=PQ2FADS-ZU
>> bootfile="uImage.linux"
>> netdev=eth0
>> ramdiskaddr=400000
>> ramdiskfile=uInitRD
>> ethact=FCC2 ETHERNET
>> testdramdata=y
>> testdramaddress=y
>> testdramwalk=n
>> x86_run_bios=on
>> bootcmd=run nfsboot
>> nfsargs=setenv bootargs $bootargs root=/dev/nfs rw
nfsroot=$serverip:$rootpath
>> setconsole=setenv bootargs $console
>> addip=setenv bootargs $bootargs
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off
>> loadaddr=0x1000000
>> nfsboot=tftp $loadaddr $bootfile; run setconsole nfsargs addip; echo
$bootargs; bootm
>> console=console=ttyS0,115200n8 console=tty0
>> stdin=serial
>> stdout=serial
>> stderr=serial
>>
>> Environment size: 891/262140 bytes
>> u-boot>
>> u-boot> boot
>> Using FCC2 ETHERNET device
>> TFTP from server 147.128.28.42; our IP address is 147.128.28.44
>> Filename 'uImage.linux'.
>> Load address: 0x1000000
>> Loading:
#################################################################
>>
#################################################################
>> ######################################################
>> done
>> Bytes transferred = 941606 (e5e26 hex)
>> console=ttyS0,115200n8 console=tty0 root=/dev/nfs rw
nfsroot=147.128.28.42:/fadsroot ip=147.128.
>> 28.44:147.128.28.42:147.128.28.1:255.255.254.0:PQ2FADS-ZU:eth0:off
>> ## Booting image at 01000000 ...
>> Image Name: Linux Kernel Image
>> Image Type: PowerPC Linux Kernel Image (gzip compressed)
>> Data Size: 941542 Bytes = 919.5 kB
>> Load Address: 00000000
>> Entry Point: 00000000
>> Verifying Checksum ... OK
>> Uncompressing Kernel Image ... OK
>>
>>
>> U-Boot 1.1.4 (Feb 15 2006 - 16:19:49)
>>
>> MPC8260 Reset Status: Check Stop, External Soft, External Hard
>>
>>
>> I have tried console=ttyCPM0,115200n8 console=tty0 and it makes no
difference. BTW, which one should be used for serial console in 2.4.x
kernel
>> for this PowerQUICC II 8280 platform? ttySx or ttyCPMx?
>> Any insight is appreciated.
>>
>The right thing is ttyS0 for 2.4.x...
>First, if that will not help, I suggest to comment out the PCI
initialization code, and to see if it will help.
>--
>Sincerely,
>Vitaly
I have taken out the PCI initialization code:
[root@ShrekII linux 4]# grep PCI .config
# CONFIG_PCI is not set
# CONFIG_DMA_NONPCI is not set
# CONFIG_NET_PCI is not set
[root@ShrekII linux 5]#
Here is the log_buf:
[root@ShrekII linux 3]# grep log_buf /fadsroot/boot/System.map
c01d40b4 b log_buf
[root@ShrekII linux 4]#
Here is what is in the log_buf after the system reboots when booting the linux kernel:
u-boot> md 0x1d40b4
001d40b4: 0007502d 0007502e 0007502f 00075030 ..P-..P...P/..P0
001d40c4: 00075031 00075032 00075033 00075034 ..P1..P2..P3..P4
001d40d4: 00075035 00075036 00075037 00075038 ..P5..P6..P7..P8
001d40e4: 00075039 0007503a 0007503b 0007503c ..P9..P:..P;..P<
001d4104: 00075041 00075042 00075043 00075044 ..PA..PB..PC..PD
001d4114: 00075045 00075046 00075047 00075048 ..PE..PF..PG..PH
001d4124: 00075049 0007504a 0007504b 0007504c ..PI..PJ..PK..PL
001d4134: 0007504d 0007504e 0007504f 00075050 ..PM..PN..PO..PP
001d4144: 00075051 00075052 00075053 00075054 ..PQ..PR..PS..PT
001d4154: 00075055 00075056 00075057 00075058 ..PU..PV..PW..PX
001d4164: 00075059 0007505a 0007505b 0007505c ..PY..PZ..P[..P\
001d4174: 0007505d 0007505e 0007505f 00075060 ..P]..P^..P_..P`
001d4184: 00075061 00075062 00075063 00075064 ..Pa..Pb..Pc..Pd
001d4194: 00075065 00075066 00075067 00075068 ..Pe..Pf..Pg..Ph
001d41a4: 00075069 0007506a 0007506b 0007506c ..Pi..Pj..Pk..Pl
u-boot>
I can't see any helpful information in this log_buf....:-<
Any insight is appreciated.
Regards,
TEH
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Olaf Hering @ 2006-03-06 7:38 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <200603061212.12815.michael@ellerman.id.au>
On Mon, Mar 06, Michael Ellerman wrote:
> I don't think I like it, on IBM firmware it takes us from this:
>
> Elapsed time since release of system processors: 26005 mins 51 secs
>
> zImage starting: loaded at 0x00400000 (sp: 0x01a1ffe0)
> Allocating 0x7edc50 bytes for kernel ...
> OF version = 'IBM,SF230_126'
> gunzipping (0x1c00000 <- 0x407000:0x6a04e4)...done 0x766880 bytes
> OF stdout device is: /vdevice/vty@30000000
> Error: You can't boot a kdump kernel from OF!
> EXIT called ok
> 0 >
>
>
> To this:
Which is likely ok because it saves us from typing .registers manually.
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Segher Boessenkool @ 2006-03-06 7:41 UTC (permalink / raw)
To: Olaf Hering; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <20060306073834.GA24869@suse.de>
> Which is likely ok because it saves us from typing .registers
> manually.
I can't say that's a great argument. How about doing the trap thing
on "known-bad" platforms only?
Segher
^ permalink raw reply
* Re: INIT:
From: Paulinha @ 2006-03-06 7:41 UTC (permalink / raw)
To: Patil, Pankaj P., linuxppc-embedded
In-Reply-To: <9B832BEB407A774AA0520CCFC23221970663EA35@CXOEXC11.AMERICAS.CPQCORP.NET>
[-- Attachment #1: Type: text/plain, Size: 7576 bytes --]
Hi,
I had the same problem two weeks ago, and my error was that I forgot to add
PTY support on the linux kernel.
Hope this help!
Paula
On 3/3/06, Patil, Pankaj P. <Pankaj.Patil@hp.com> wrote:
>
> I do have /dev/console in my file system. In fact , i used ethereal on
> the host to see how far the INIT goes.
> I saw all the usual NFS Lookup calls like /lib, /ld-2.3.1.so ..... /libc-
> 2.31.so
> The last NFS lookup call looks like DH:0xbea72a4a/tty0
> There are bunch of read replys after that but no more NFS lookups. Is it
> normal to see a NFS Lookup that looks like 0xbea72a4a/tty0 ??
> What should be the next NFS Lookup call?
> I did some searching from previous posts but haven't found exactly what i
> am looking for. I am attaching a link to something that looks similar to my
> problem. Just in case, someone's having trouble understanding my issue.
> http://ozlabs.org/pipermail/linuxppc-embedded/2004-August/015250.html
>
> Thanks
> pankaj
>
> -----Original Message-----
> From: atul.sabharwal@exgate.tek.com
> [mailto:atul.sabharwal@exgate.tek.com]
> Sent: Tuesday, February 28, 2006 6:03 PM
> To: Patil, Pankaj P.
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: INIT:
>
>
> Easy answer is do you have /dev/console in your file system. Glibc
> opens
> /dev/console and the kernel uses /dev/ttyS0 as specified on the command
> line. There should not be any app calling uart_close as the console
> deriver
> should be opening it.
>
> --
> Atul
>
> Hi,
> I am running u-boot & linux2.6.12 on a custom ppc board(functional HW).
> I can get to the point where u-boot loads the kernel, kernel does all
> the initialization, loads the Root File System over NFS & calls the
> Init process.
> Next, i am expecting to see a shell prompt. I am not sure where in the
> Init process i am failing. I have written my own serial driver(Philips
> SC28L194 Quad UART--under development-possible culprit). The printks
> work just fine.
> All i see is the kernel calling the Init process & after a minute or so
> i see uart_close call.
> The kernel runs just fine & responds to ping.
> What can trigger a uart_close??(tty_release calls release_dev calls
> uart_close) I have a JTAG debugger. What's the best way to debug once
> Init process is running??
>
>
>
> I am attaching a dump of my console:
> U-Boot 1.1.3 (Dec 16 2005 - 16:00:23), Build: 0.4.1
>
> SysClock = 120Mhz , TClock = 120Mhz
> CPU: MPC7447A v1.1 @ 960 MHz
> CPU bus mode : 60x
>
> DRAM: SPD Checksum ok!
> -- DIMM1 has 2 banks
> -- DIMM2 has 0 banks
> ECC Initialization of Bank 0: Done
> CAS Latency = 2 tRP = 3 tRAS = 6 tRCD=3
> Total SDRAM memory is 1024 MB
> Now running in RAM - U-Boot at: 00fc0000
> Remapped Internal SRAM to 0xf2000000
> Remapped Flash Card to 0xffc00000
> FLASH: 4 MB
> Addresses 32M - 0M are saved for the U-Boot usage.
> Mem malloc Initialization (32M - 16M): Done
>
> Internal SRAM ECC Initialization: Done
> ***Phy Reset***
> Phy Auto-Negotiation Bit ReEnabled in SW
> Net: , mv_enet1 [PRIME]
> Hit any key to stop autoboot: 0
> Ethernet status port 1: Link up, Full Duplex, Speed 100 Mbps
> Using mv_enet1 device
> TFTP from server 192.168.1.1; our IP address is 192.168.1.2
> Filename 'uImage'.
> Load address: 0x400000
> Loading:
> #################################################################
>
> #################################################################
>
> #################################################################
> ########################
> done
> Bytes transferred = 1119847 (111667 hex)
>
> ### Network statistics: ###
> --------------------------
> Packets received: 2192
> Packets send: 2191
> Received bytes: 2347583
> Send bytes: 100803
> ## Booting image at 00400000 ...
> Image Name: Linux-2.6.12
> Created: 2006-02-14 0:37:17 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1119783 Bytes = 1.1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## cmdline at 0x007FFF00 ... 0x007FFF98
> memstart = 0x00000000
> memsize = 0x40000000
> flashstart = 0xFFC00000
> flashsize = 0x00400000
> flashoffset = 0x00000000
> sramstart = 0xF8000000
> sramsize = 0x00400000
> bootflags = 0x00000001
> intfreq = 960 MHz
> busfreq = 120 MHz
> ethaddr = 64:00:00:00:00:00
> IP addr = 192.168.1.2
> baudrate = 115200 bps
> tclk = 0 MHz
> uboot_ver = 0.4.1a
> L3 was init = 0
> Total memory = 768MB; using 2048kB for hash table (at c0400000)
> Linux version 2.6.12 (root@RHEL40) (gcc version 3.3.3 (DENX ELDK 3.1.1
> 3.3.3-10)) #154 Mon Feb 13 17:36:35 MST 2006
> System Identification:
> Freescale 74XX port
> Built 1 zonelists
> Kernel command line: console=ttyS0,115200 root=/dev/nfs rw
> nfsroot=192.168.1.1:/target/chestnut/rootfs
> ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:DB64xxx:eth0:non
> e
> PID hash table entries: 4096 (order: 12, 65536 bytes)
> time_init: decrementer frequency = 30.000000 MHz
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 774400k available (1596k kernel code, 556k data, 344k init, 0k
> highmem)
> Mount-cache hash table entries: 512
>
> NET: Registered protocol family 16
> PCI: Probing PCI hardware
> JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
> Generic RTC Driver v1.07
> Serial: SC28L194 driver 4 ports
> ttyS0 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> ttyS1 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> ttyS2 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> ttyS3 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> MV-643xx 10/100/1000 Ethernet Driver
> eth0: port 1 with MAC address 00:11:85:da:0b:02
> eth0: RX NAPI Enabled
> physmap flash device: 400000 at ffc00000
> mice: PS/2 mouse device common for all mice
> NET: Registered protocol family 2
> IP: routing cache hash table of 8192 buckets, 64Kbytes
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> IP-Config: Complete:
> device=eth0, addr=192.168.1.2, mask=255.255.255.0, gw=192.168.1.1,
> host=DB64xxx, domain=, nis-domain=(none),
> bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=
> Looking up port of RPC 100003/2 on 192.168.1.1
> Looking up port of RPC 100005/1 on 192.168.1.1
> VFS: Mounted root (nfs filesystem).
> Freeing unused kernel memory: 344k init
>
>
> Any help appreceated.
> Thanks
> pankaj
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 9937 bytes --]
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Olaf Hering @ 2006-03-06 7:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <590CA2B3-AACE-4B69-930D-9A66A42FFC83@kernel.crashing.org>
On Mon, Mar 06, Segher Boessenkool wrote:
> >Which is likely ok because it saves us from typing .registers
> >manually.
>
> I can't say that's a great argument. How about doing the trap thing
> on "known-bad" platforms only?
Can you do anything at that time anyway? I mean, reset-all pending
either way.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox