* 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: 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: 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 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: 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
* 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: 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
* 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: 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: 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: 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
* 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
* [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
* 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
* 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: [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
* [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: boot failure on lite5200b board
From: Sylvain Munaut @ 2006-03-04 9:17 UTC (permalink / raw)
To: #LI JIANGGAN#; +Cc: haidong_feng, linuxppc-embedded
In-Reply-To: <84A109BF918D934CB46ACF33BCE187C002D54D96@mail02.student.main.ntu.edu.sg>
Hi,
#LI JIANGGAN# wrote:
> Thanks John, the Kernel now boots well. However it gives a kernel panic
> while mounting the root file sysem over NFS:
>
> Looking up port of RPC 100003/2 on 10.190.3.103
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101
> Root-NFS: Unable to get nfsd port number from server, using default
>
> I couldn't figure out why error 101 /* Network is unreachable */ is
> given. Below is my current U-boot settings and a snapshot of the booting:
Didn't I told you to try the tree I on http://gitbits.246tnt.com ?
I don't know the tree you're using but it doesn't seem to be mine ...
(nor any of the previous version i published).
I you want to have the most "complete" stuff i publish, clone the
mainstream, pull from my ide branch and then pull from the bestcomm branch.
There is also the denx tree but I don't know it's status.
> Linux version 2.6.11.7 (root@bob) (gcc version 3.3.2) #1 Tue Sep 6
> 22:40:03 UTC 2005
^^^^^^^^^^^^^^^^^^^^^^^^^^
my tree is based on something more recent
> Real-Time Preemption Support (c) Ingo Molnar
> Built 1 zonelists
> Kernel command line: console=ttyS0,115200
^^^^^^^^^^^^^^^^^^^^
You would see nothing with the tree of gitbits.246tNt.com with that
command line. You need ttyPSC0 ...
> nfsroot=10.190.3.103:/opt/eldk-4-0/nfs root=/dev/nfs rw
> PID hash table entries: 2048 (order: 11, 32768 bytes)
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Memory: 256268k available (2336k kernel code, 896k data, 140k init, 0k
> highmem)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> BUG: scheduling while atomic: swapper/0x00000001/0
> caller is schedule+0x50/0xe8
> Call trace:
> [c0006bd8] dump_stack+0x18/0x28
> [c0242818] __sched_text_start+0x69c/0x6a0
> [c024286c] schedule+0x50/0xe8
> [c0003f00] syscall_exit_work+0x108/0x10c
> [c030c578] proc_root_init+0x144/0x150
> [c0320000] 0xc0320000
> [c02fe624] start_kernel+0x180/0x1b8
> [000035fc] 0x35fc
> spawn_desched_task(00000000)
> desched cpu_callback 3/00000000
> ksoftirqd started up.
> softirq RT prio: 24.
> desched cpu_callback 2/00000000
> desched thread 0 started up.
> NET: Registered protocol family 16
>
> PCI: Probing PCI hardware
> SCSI subsystem initialized
> usbcore: registered new driver usbfs
> usbcore: registered new driver hub
> JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
> ppdev: user-space parallel port driver
> Serial: MPC52xx PSC driver
> ttyS0 at MMIO 0xf0002000 (irq = 39) is a MPC52xx PSC
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
> RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
> loop: loaded (max 8 devices)
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ipb=132MHz, set clock period to 7
> GPIO config: 91051024
> ATA invalid: 01000000
> ATA hostcnf: 03000000
> ATA pio1 : 100a0a00
> ATA pio2 : 02040600
> XLB Arb cnf: 0000a366
> mpc52xx_ide: Setting up IDE interface ide0...
> flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x0 in
> 8-bit bank
> flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x1000000
> in 8-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> flash chip on the Lite5200/Lite5200B: CFI does not contain boot bank
> location. Assuming top.
> number of CFI chips: 2
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> Creating 7 MTD partitions on "flash chip on the Lite5200/Lite5200B":
> 0x00000000-0x01000000 : "Filesystem"
> 0x01000000-0x01040000 : "BootLOW"
> 0x01040000-0x01060000 : "EnvLOW"
> 0x01060000-0x01d00000 : "Spare"
> 0x01d00000-0x01f00000 : "Kernel"
> 0x01f00000-0x01f40000 : "BootHIGH"
> 0x01f40000-0x01f60000 : "EnvHIGH"
> ocp-ohci 02: new USB bus registered, assigned bus number 1
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> Initializing USB Mass Storage driver...
> usbcore: registered new driver usb-storage
> USB Mass Storage support registered.
> usbcore: registered new driver usbhid
> drivers/usb/input/hid-core.c: v2.0:USB HID core driver
> mice: PS/2 mouse device common for all mice
> i2c /dev entries driver
> i2c-algo-52xx.o: scanning bus Lite5200 I2C module #1 interface...
> ................................................................................................................................
> i2c-lite5200.o: I2C module #1 installed
> i2c-algo-52xx.o: scanning bus Lite5200 I2C module #2 interface...
> ................................................................................(0x50)..............................................(0x7f)
> i2c-lite5200.o: I2C module #2 installed
> Advanced Linux Sound Architecture Driver Version 1.0.8 (Thu Jan 13
> 09:39:32 2005 UTC).
> ALSA device list:
> No soundcards found.
> NET: Registered protocol family 2
> IP: routing cache hash table of 256 buckets, 16Kbytes
> TCP established hash table entries: 16384 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 16384 (order: 7, 917504 bytes)
> TCP: Hash tables configured (established 16384 bind 16384)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> Looking up port of RPC 100003/2 on 10.190.3.103
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101
> Root-NFS: Unable to get nfsd port number from server, using default
> Looking up port of RPC 100005/1 on 10.190.3.103
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101
> Root-NFS: Unable to get mountd port number from server, using default
> RPC: sendmsg returned error 101
> mount: RPC call returned error 101
> Root-NFS: Server returned error -101 while mounting /opt/eldk-4-0/nfs
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "nfs" or unknown-block(2,0)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(2,0)
> <0>Rebooting in 180 seconds..
^ permalink raw reply
* Re: Linux on PPC
From: David Hawkins @ 2006-03-04 2:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060304020938.00774352627@atlas.denx.de>
Hi Wolfgang,
> You don't get it.
Ok, I'll read-up and try to 'get it'.
Thanks
Dave
^ permalink raw reply
* Different Page Size Support in Linux on PPC870
From: atul.sabharwal @ 2006-03-04 2:38 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
On PPC870, does the kernel only support 4K pages? To reduce the size of
page table (level & level 2), would 8M page be a better choice on a
custom=20
board? It's a no swap configuration. Memory load is critical in our
design on this project.
Comments?
Thanks,
Atul
^ permalink raw reply
* Re: Linux on PPC
From: Wolfgang Denk @ 2006-03-04 2:09 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <4408A1D3.8010506@ovro.caltech.edu>
In message <4408A1D3.8010506@ovro.caltech.edu> you wrote:
>
> > Still not right. Even the physical memory is software settable. What
> > matters is what chip-select things are hooked up to, and then map those
> > chip selects correctly (size, base address, access with and so on)
>
> Thats what I meant with 'redefined in hardware'. But yes, redefined
> up to the limit of the wiring on the board of course (chip-selects
> and bus widths). That's where having the board schematic is
> invaluable.
You don't get it. You can map - for example - your flash to physical
address 0x0000 or 0x04000000 or 0x40000000 or 0xFFF00000 as you like
- without any changes to the hardware, and without using the MMU.
Mind: that's all *physical* addresses.
> manual for the 440EP Yosemite board), and then setup U-Boot and
> Linux to program the TLBs to translate to those same addresses.
No. U-Boot does not use the MMU.
> when I booted Linux, I took a look and found that on the whole, Linux
> didn't touch too much of the things setup by U-Boot, i.e., the
> responsibility for setting up the Linux environment was mainly
> the job of the bootloader.
Wrong again. Linux completely re-initializes the whole memory
management.
> So, if I had a board with a custom bootloader, I would be
> concerned that the bootloader might not know enough about
> Linux, to setup the hardware correctly.
>
> Does that sound right?
No, it's wrong.
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
"Language shapes the way we think, and determines what we can think
about." - B. L. Whorf
^ permalink raw reply
* Re: Linux on PPC
From: Wolfgang Denk @ 2006-03-04 2:05 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <44087473.6020905@ovro.caltech.edu>
In message <44087473.6020905@ovro.caltech.edu> you wrote:
>
> > Many memory maps (especially those provides with some eval boards for
> > demonstration purpose) will NOT work with Linux. Remember that the
> > memory map is usually not cast in silicon, but implemented in
> > software, so you can change it as needed.
>
> Right, thats I made sure to say; Physical Memory Map.
That's what I mean: the physical memory map is usually set up in
software, so it can be changed to your needs.
> For example, on the Artesyn manual on their PrPMC they give a
> physical memory map, and in the Yosemite board, there is a
> physical memory map. I know many of the memory areas can be
> redefined in hardware to have a different memory location, but
> its still a physical address.
...which usually can be reprogrammed in software.
> Now, when the bootloader loads, eg. U-Boot, it sets up the
> memory management. Now this is where my understanding gets
> shakey, since I haven't looked at much of the code, so perhaps
> you can clarify. The translation unit (TLB) maps virtual addresses
> (or should that be MMU output addresses) into physical addresses,
U-Boot usually does not use the MMU.
> What are the basic requirements for a Linux memory map then?
See the FAQ.
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
It is surely a great calamity for a human being to have no ob-
sessions. - Robert Bly
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Segher Boessenkool @ 2006-03-04 0:09 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060303232334.GA9577@suse.de>
>> The stack pointer is required to be 16-byte aligned when the
>> client program is started, on 32-bit as well.
>
> See http://ozlabs.org/pipermail/linuxppc-dev/2006-March/021342.html
>
> Either yaboot and/or zImage need to force a stack alignment, or we
> apply
> the 2 liner.
Yaboot should do it. Of course, it won't hurt if the kernel will
do it itself, too...
Segher
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Paul Nasrat @ 2006-03-03 23:45 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060303232334.GA9577@suse.de>
On Sat, 2006-03-04 at 00:23 +0100, Olaf Hering wrote:
> On Fri, Mar 03, Segher Boessenkool wrote:
>
> > > The stackpointer came from 32bit code, which appearently has different
> > > alignment rules than 64bit code. The chain was yaboot -> zImage ->
> > > vmlinux
> > > Force the stackpointer to be 16 byte aligned.
> >
> > The stack pointer is required to be 16-byte aligned when the
> > client program is started, on 32-bit as well.
>
> See http://ozlabs.org/pipermail/linuxppc-dev/2006-March/021342.html
>
> Either yaboot and/or zImage need to force a stack alignment, or we apply
> the 2 liner.
Happy to look at/receive patches for yaboot. I'll look on Monday.
Paul
^ 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