* [U-Boot] Fw:
From: jobhunts02 at aol.com @ 2011-10-31 4:33 UTC (permalink / raw)
To: u-boot
http://greatlandwelding.com/detail.php?id=26
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v6 1/2] Add AACI audio playback support to the ARM Versatile/PB platform
From: andrzej zaborowski @ 2011-10-31 4:27 UTC (permalink / raw)
To: Peter Maydell; +Cc: Mathieu Sonet, qemu-devel, patches
In-Reply-To: <1319795738-18205-2-git-send-email-peter.maydell@linaro.org>
On 28 October 2011 11:55, Peter Maydell <peter.maydell@linaro.org> wrote:
> From: Mathieu Sonet <contact@elasticsheep.com>
>
> This driver emulates the ARM AACI interface (PL041) connected to a LM4549 codec.
> It enables audio playback for the Versatile/PB platform.
Thanks, pushed both changes.
Cheers
^ permalink raw reply
* May I ask a question about sched_rt.c?
From: MING ZHOU @ 2011-10-31 3:35 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <CAFf0ej4V6HmqGVQ+6G-eh=nMR3nES9UZrNbD=xBRnbgR5SZ8KA@mail.gmail.com>
Hi all,
May I ask a question about scheduler (sched_rt.c)? I want to make
sure a patch related is valid or not.
I encountered a kernel panic recently which caused by BUG_ON in
pick_next_pushable_task ( my kernel version is 2.6.35, on arm
platform).
static struct task_struct *pick_next_pushable_task(struct rq *rq)
{
...
BUG_ON(task_current(rq, p)); <------------ panic here!!!
...
}
<4>[17583.180664] [<c00a3888>] (pick_next_pushable_task+0x4c/0xa4)
from [<c00ae21c>] (push_rt_task+0x20/0x264)
<4>[17583.180725] [<c00ae21c>] (push_rt_task+0x20/0x264) from
[<c00ae554>] (post_schedule_rt+0x14/0x20)
<4>[17583.180816] [<c00ae554>] (post_schedule_rt+0x14/0x20) from
[<c069352c>] (schedule+0x738/0x7c8)
I checked patch history related to push_rt_task, and I think the
following patch may be the reason, since if dequeue task improperly,
it may ruin task pointer by mistake.
https://lkml.org/lkml/2011/8/14/71
Commit-ID: 311e800e16f63d909136a64ed17ca353a160be59
Author: Hillf Danton <dhillf@gmail.com>
sched, rt: Fix rq->rt.pushable_tasks bug in push_rt_task()
Do not call dequeue_pushable_task() when failing to push an eligible
task, as it remains pushable, merely not at this particular moment.
Signed-off-by: Hillf Danton <dhillf@gmail.com>
Signed-off-by: Mike Galbraith <mgalbraith@gmx.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Yong Zhang <yong.zhang0@gmail.com>
And I also noticed in commit history of sched_rt.c, I found the
similar patch is submitted before at 2008.
However, it was not picked up in latest kernel code. So, I am
wondering whether this patch is valid?
commit 1563513d34ed4b12ef32bc2adde4a53ce05701a1
Author: Gregory Haskins <ghaskins@novell.com>
Date: Mon Dec 29 09:39:53 2008 -0500
RT: fix push_rt_task() to handle dequeue_pushable properly
A panic was discovered by Chirag Jog where a BUG_ON sanity check
in the new "pushable_task" logic would trigger a panic under
certain circumstances:
http://lkml.org/lkml/2008/9/25/189
Gilles Carry discovered that the root cause was attributed to the
pushable_tasks list getting corrupted in the push_rt_task logic.
This was the result of a dropped rq lock in double_lock_balance
allowing a task in the process of being pushed to potentially migrate
away, and thus corrupt the pushable_tasks() list.
I traced back the problem as introduced by the pushable_tasks patch
that went in recently. There is a "retry" path in push_rt_task()
that actually had a compound conditional to decide whether to
retry or exit. I missed the meaning behind the rationale for the
virtual "if(!task) goto out;" portion of the compound statement and
thus did not handle it properly. The new pushable_tasks logic
actually creates three distinct conditions:
1) an untouched and unpushable task should be dequeued
2) a migrated task where more pushable tasks remain should be retried
3) a migrated task where no more pushable tasks exist should exit
The original logic mushed (1) and (3) together, resulting in the
system dequeuing a migrated task (against an unlocked foreign run-queue
nonetheless).
To fix this, we get rid of the notion of "paranoid" and we support the
three unique conditions properly. The paranoid feature is no longer
relevant with the new pushable logic (since pushable naturally limits
the loop) anyway, so lets just remove it.
Reported-By: Chirag Jog <chirag@linux.vnet.ibm.com>
Found-by: Gilles Carry <gilles.carry@bull.net>
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Best Regards,
Jane Zhou
^ permalink raw reply
* Re: PROBLEM: Kernel panic and system crash during RAID disk failure
From: Yongqiang Yang @ 2011-10-31 4:25 UTC (permalink / raw)
To: Darko; +Cc: NeilBrown, Thomas Gleixner, linux-kernel, linux-ext4
In-Reply-To: <Pine.LNX.4.64.1110301833180.1168@hytron.hytron.net>
Hi Darko,
The bug has been fixed by commit 0449641130 ext4: Init timer earlier
to avoid a kernel panic in __save_error_info.
http://lists.openwall.net/linux-ext4/2011/03/29/5
I suspect you mounted ext2/3 partition using ext4 module.
Yongqiang.
On Mon, Oct 31, 2011 at 11:13 AM, Darko <darko@hytron.net> wrote:
> Thank you for your reply!
>
> I wanted to add to this that I was able to replicate the problem with ext3
> and ext2 file systems as well. They both hard lock the system, and the only
> way to recovery is to push the reset button. I can see the trace error on
> the screen, but I am unable to do anything with it, since it goes by so fast
> that the portion which says "kernel BUG" is invisible. I assume they both
> have similar issues with the code in kernel/timer.c
>
> On the other hand, I tried using raiserfs 3.5 tonight, and I got
> input/output error as expected. The system did not crash. Just another proof
> that a bug is laying somewhere in the ext2/3/4 file system.
>
> When someone comes up with a patch, I am willing to try it out and feed you
> back with the report.
>
> Hope this helps.
>
> Thank You,
>
> Darko Kraus
>
>
> On Sun, 30 Oct 2011, NeilBrown wrote:
>
>> Date: Sun, 30 Oct 2011 19:05:48 +1100
>> From: NeilBrown <neilb@suse.de>
>> To: Darko <darko@hytron.net>
>> Cc: Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
>> linux-ext4@vger.kernel.org
>> Subject: Re: PROBLEM: Kernel panic and system crash during RAID disk
>> failure
>>
>> On Sun, 30 Oct 2011 03:27:28 -0400 (EDT) Darko <darko@hytron.net> wrote:
>>
>>> Hello,
>>>
>>> I have been doing some testing with the md RAID driver and I think I
>>> discovered a problem with it.
>>> Everything was performed on a system with a single hard drive using loop
>>> devices as virtual raid devices.
>>> So here is the setup:
>>> /dev/sdc is my main drive that hold entire Linux OS and has one
>>> partition.
>>> in the /tmp I created 7 files, 100MB each and associated them with loop
>>> devices:
>>>
>>> losetup -a
>>> /dev/loop0: [0821]:294820 (/var/tmp/raid-0)
>>> /dev/loop1: [0821]:294857 (/var/tmp/raid-1)
>>> /dev/loop2: [0821]:300120 (/var/tmp/raid-2)
>>> /dev/loop3: [0821]:301073 (/var/tmp/raid-3)
>>> /dev/loop4: [0821]:301074 (/var/tmp/raid-4)
>>> /dev/loop5: [0821]:301075 (/var/tmp/raid-5)
>>> /dev/loop6: [0821]:301076 (/var/tmp/raid-6)
>>>
>>> The next step was, created an RAID6 array:
>>> mdadm --create /dev/md10 --level=6 -raid-deviced=7 /dev/loop[0-6]
>>>
>>> Here is how it looks so far:
>>>
>>> cat /proc/mdstat
>>> Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
>>> md10 : active raid6 loop6[6] loop5[5] loop4[4] loop3[3] loop2[2] loop1[1]
>>> loop0[0]
>>> 499200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [7/7]
>>> [UUUUUUU]
>>>
>>>
>>> Then the filesystem...
>>> mkfs.ext4 -b 4096 -i 4096 -m 0 /dev/md10
>>>
>>> Mounting the file system to a folder called 'A' right in the root of my
>>> system:
>>>
>>> mount /dev/md10 /A
>>>
>>> Then I copied a few files on that file system. So far everything is good.
>>>
>>> Then I purposly failed 2 drives:
>>> mdadm --manage /dev/md10 --fail /dev/loop0
>>> mdadm --manage /dev/md10 --fail /dev/loop1
>>>
>>> The array continues to run fine in degraded mode. I was wondering what
>>> would happen if another drive fails. So while I was doing a write
>>> operating right in that filesystem (/dev/md10) using:
>>> dd if=/dev/zero of=testfile bs=1k count=360000 ...
>>>
>>> ...quickly switched to a different console and entered the command:
>>> mdadm --manage /dev/md10 --fail /dev/loop2
>>>
>>> ...which made 3 failed drives and the array can no longer work...
>>>
>>> Well I would be happy to see just the array not working, but kernel panic
>>> in both versions 2.6.37.4 and 3.0.8 made me worry that it is serious bug
>>> and appears to be in older and newer kernels as well.
>>> I repeated this several times, and mostly the machine gets locked up with
>>> kernel panic. But once I was able to get it not to lock up all the way,
>>> and that is how I have dmesg output.
>>>
>>> The attached files include dmesg from the system startup until the bug
>>> trace, and some additional information regarding my system that might be
>>> helpful.
>>>
>>> For any additional question, please feel free to contact me!
>>>
>>> I hope this info helps someone find and resolve the problem in the code.
>>>
>>
>> The important part of your kernel log message is:
>>
>>
>> [ 1227.766202] ------------[ cut here ]------------
>> [ 1227.766259] kernel BUG at kernel/timer.c:681!
>> [ 1227.766311] invalid opcode: 0000 [#1] SMP
>> [ 1227.766365] last sysfs file: /sys/devices/virtual/block/md10/dev
>> [ 1227.766419] Modules linked in:
>> [ 1227.766471]
>> [ 1227.766520] Pid: 1507, comm: mount Not tainted 2.6.37.6-v5.0 #7
>> MICRO-STAR INTERNATIONAL CO., LTD MS-7142/MS-7142
>> [ 1227.766633] EIP: 0060:[<c104f960>] EFLAGS: 00010246 CPU: 0
>> [ 1227.766690] EIP is at mod_timer+0x210/0x250
>> [ 1227.766742] EAX: 00000000 EBX: f5494e1c ECX: 00000000 EDX: 00000000
>> [ 1227.766796] ESI: 00000000 EDI: 05348416 EBP: f54a3c90 ESP: f54a3c74
>> [ 1227.766851] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>> [ 1227.766904] Process mount (pid: 1507, ti=f54a2000 task=f2068880
>> task.ti=f54a2000)
>> [ 1227.767002] Stack:
>> [ 1227.767003] f2068880 f54b159c 00000010 00000000 f1f8e400 f4efc57c
>> 0000128d f54a3ca8
>> [ 1227.767003] c11cb7ba c17d4e52 f4efc400 00000124 00000000 f54a3cb4
>> c11ce4e6 ecee6318
>> [ 1227.767003] f54a3cdc c11cf7cc ecec7578 00000124 00000000 f4efc400
>> f54a3cd4 00000124
>> [ 1227.767003] Call Trace:
>> [ 1227.767003] [<c11cb7ba>] ? __save_error_info.clone.61+0x7a/0xf0
>> [ 1227.767003] [<c11ce4e6>] ? save_error_info+0x16/0x30
>> [ 1227.767003] [<c11cf7cc>] ? ext4_error_inode+0x4c/0xf0
>> [ 1227.767003] [<c11b57e1>] ? __ext4_get_inode_loc+0x201/0x410
>> [ 1227.767003] [<c110b62a>] ? inode_init_always+0x1aa/0x1c0
>> [ 1227.767003] [<c11b72f9>] ? ext4_iget+0x59/0x6f0
>> [ 1227.767003] [<c11d2716>] ? ext4_fill_super+0x1ab6/0x2c70
>> [ 1227.767003] [<c114896f>] ? disk_name+0xbf/0xd0
>> [ 1227.767003] [<c10fa119>] ? mount_bdev+0x179/0x1c0
>> [ 1227.767003] [<c11d0c60>] ? ext4_fill_super+0x0/0x2c70
>> [ 1227.767003] [<c11ca17f>] ? ext4_mount+0x1f/0x30
>> [ 1227.767003] [<c11d0c60>] ? ext4_fill_super+0x0/0x2c70
>> [ 1227.767003] [<c10f9835>] ? vfs_kern_mount+0x75/0x250
>> [ 1227.767003] [<c110df03>] ? get_fs_type+0x33/0xb0
>> [ 1227.767003] [<c11ca160>] ? ext4_mount+0x0/0x30
>> [ 1227.767003] [<c10f9a6e>] ? do_kern_mount+0x3e/0xe0
>> [ 1227.767003] [<c111080f>] ? do_mount+0x35f/0x6b0
>> [ 1227.767003] [<c10d47c9>] ? strndup_user+0x49/0x70
>> [ 1227.767003] [<c1110e0b>] ? sys_mount+0x6b/0xa0
>> [ 1227.767003] [<c17b550c>] ? syscall_call+0x7/0xb
>> [ 1227.767003] Code: fe ff ff 8b 0e 89 4d e4 8b 46 04 83 c6 08 89 f9 89 da
>> ff 55 e4 8b 06 85 c0 89 45 e4 75 ea e9 aa fe ff ff 8b 75 ec e9 ee fe ff ff
>> <0f> 0b 8b 55 04 89 d8 e8 34 f9 ff ff e9 2a fe ff ff 8b 35 30 b8
>> [ 1227.767003] EIP: [<c104f960>] mod_timer+0x210/0x250 SS:ESP
>> 0068:f54a3c74
>> [ 1227.770073] ---[ end trace d7b3d7a67954d202 ]---
>>
>>
>> which happens after:
>>
>> [ 1137.167043] Aborting journal on device md10-8.
>> [ 1137.167058] Buffer I/O error on device md10, logical block 139265
>> [ 1137.167060] lost page write due to I/O error on md10
>> [ 1137.167065] JBD2: I/O error detected when updating journal superblock
>> for md10-8.
>> [ 1137.660922] Buffer I/O error on device md10, logical block 1
>> [ 1137.660926] lost page write due to I/O error on md10
>> [ 1137.660932] EXT4-fs error (device md10): ext4_journal_start_sb:260:
>> Detected aborted journal
>> [ 1137.661046] EXT4-fs (md10): Remounting filesystem read-only
>> [ 1137.661103] EXT4-fs (md10): previous I/O error to superblock detected
>> [ 1137.661313] Buffer I/O error on device md10, logical block 1
>> [ 1137.661315] lost page write due to I/O error on md10
>> [ 1219.891363] EXT4-fs (md10): previous I/O error to superblock detected
>> [ 1220.050654] Buffer I/O error on device md10, logical block 1
>> [ 1220.050657] lost page write due to I/O error on md10
>> [ 1220.050663] EXT4-fs error (device md10): ext4_put_super:728: Couldn't
>> clean up the journal
>>
>> and some more "Buffer I/O error"s.
>>
>> So it looks like an ext4 issue.
>>
>> I have Cc:ed the appropriate list.
>>
>> Thanks for the report.
>>
>> NeilBrown
>>
>>
>
>
> --
> Darko Kraus
> Enterprise Network Administrator
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Best Wishes
Yongqiang Yang
^ permalink raw reply
* Re: PROBLEM: Kernel panic and system crash during RAID disk failure
From: Yongqiang Yang @ 2011-10-31 4:25 UTC (permalink / raw)
To: Darko; +Cc: NeilBrown, Thomas Gleixner, linux-kernel, linux-ext4
In-Reply-To: <Pine.LNX.4.64.1110301833180.1168@hytron.hytron.net>
Hi Darko,
The bug has been fixed by commit 0449641130 ext4: Init timer earlier
to avoid a kernel panic in __save_error_info.
http://lists.openwall.net/linux-ext4/2011/03/29/5
I suspect you mounted ext2/3 partition using ext4 module.
Yongqiang.
On Mon, Oct 31, 2011 at 11:13 AM, Darko <darko@hytron.net> wrote:
> Thank you for your reply!
>
> I wanted to add to this that I was able to replicate the problem with ext3
> and ext2 file systems as well. They both hard lock the system, and the only
> way to recovery is to push the reset button. I can see the trace error on
> the screen, but I am unable to do anything with it, since it goes by so fast
> that the portion which says "kernel BUG" is invisible. I assume they both
> have similar issues with the code in kernel/timer.c
>
> On the other hand, I tried using raiserfs 3.5 tonight, and I got
> input/output error as expected. The system did not crash. Just another proof
> that a bug is laying somewhere in the ext2/3/4 file system.
>
> When someone comes up with a patch, I am willing to try it out and feed you
> back with the report.
>
> Hope this helps.
>
> Thank You,
>
> Darko Kraus
>
>
> On Sun, 30 Oct 2011, NeilBrown wrote:
>
>> Date: Sun, 30 Oct 2011 19:05:48 +1100
>> From: NeilBrown <neilb@suse.de>
>> To: Darko <darko@hytron.net>
>> Cc: Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
>> linux-ext4@vger.kernel.org
>> Subject: Re: PROBLEM: Kernel panic and system crash during RAID disk
>> failure
>>
>> On Sun, 30 Oct 2011 03:27:28 -0400 (EDT) Darko <darko@hytron.net> wrote:
>>
>>> Hello,
>>>
>>> I have been doing some testing with the md RAID driver and I think I
>>> discovered a problem with it.
>>> Everything was performed on a system with a single hard drive using loop
>>> devices as virtual raid devices.
>>> So here is the setup:
>>> /dev/sdc is my main drive that hold entire Linux OS and has one
>>> partition.
>>> in the /tmp I created 7 files, 100MB each and associated them with loop
>>> devices:
>>>
>>> losetup -a
>>> /dev/loop0: [0821]:294820 (/var/tmp/raid-0)
>>> /dev/loop1: [0821]:294857 (/var/tmp/raid-1)
>>> /dev/loop2: [0821]:300120 (/var/tmp/raid-2)
>>> /dev/loop3: [0821]:301073 (/var/tmp/raid-3)
>>> /dev/loop4: [0821]:301074 (/var/tmp/raid-4)
>>> /dev/loop5: [0821]:301075 (/var/tmp/raid-5)
>>> /dev/loop6: [0821]:301076 (/var/tmp/raid-6)
>>>
>>> The next step was, created an RAID6 array:
>>> mdadm --create /dev/md10 --level=6 -raid-deviced=7 /dev/loop[0-6]
>>>
>>> Here is how it looks so far:
>>>
>>> cat /proc/mdstat
>>> Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
>>> md10 : active raid6 loop6[6] loop5[5] loop4[4] loop3[3] loop2[2] loop1[1]
>>> loop0[0]
>>> 499200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [7/7]
>>> [UUUUUUU]
>>>
>>>
>>> Then the filesystem...
>>> mkfs.ext4 -b 4096 -i 4096 -m 0 /dev/md10
>>>
>>> Mounting the file system to a folder called 'A' right in the root of my
>>> system:
>>>
>>> mount /dev/md10 /A
>>>
>>> Then I copied a few files on that file system. So far everything is good.
>>>
>>> Then I purposly failed 2 drives:
>>> mdadm --manage /dev/md10 --fail /dev/loop0
>>> mdadm --manage /dev/md10 --fail /dev/loop1
>>>
>>> The array continues to run fine in degraded mode. I was wondering what
>>> would happen if another drive fails. So while I was doing a write
>>> operating right in that filesystem (/dev/md10) using:
>>> dd if=/dev/zero of=testfile bs=1k count=360000 ...
>>>
>>> ...quickly switched to a different console and entered the command:
>>> mdadm --manage /dev/md10 --fail /dev/loop2
>>>
>>> ...which made 3 failed drives and the array can no longer work...
>>>
>>> Well I would be happy to see just the array not working, but kernel panic
>>> in both versions 2.6.37.4 and 3.0.8 made me worry that it is serious bug
>>> and appears to be in older and newer kernels as well.
>>> I repeated this several times, and mostly the machine gets locked up with
>>> kernel panic. But once I was able to get it not to lock up all the way,
>>> and that is how I have dmesg output.
>>>
>>> The attached files include dmesg from the system startup until the bug
>>> trace, and some additional information regarding my system that might be
>>> helpful.
>>>
>>> For any additional question, please feel free to contact me!
>>>
>>> I hope this info helps someone find and resolve the problem in the code.
>>>
>>
>> The important part of your kernel log message is:
>>
>>
>> [ 1227.766202] ------------[ cut here ]------------
>> [ 1227.766259] kernel BUG at kernel/timer.c:681!
>> [ 1227.766311] invalid opcode: 0000 [#1] SMP
>> [ 1227.766365] last sysfs file: /sys/devices/virtual/block/md10/dev
>> [ 1227.766419] Modules linked in:
>> [ 1227.766471]
>> [ 1227.766520] Pid: 1507, comm: mount Not tainted 2.6.37.6-v5.0 #7
>> MICRO-STAR INTERNATIONAL CO., LTD MS-7142/MS-7142
>> [ 1227.766633] EIP: 0060:[<c104f960>] EFLAGS: 00010246 CPU: 0
>> [ 1227.766690] EIP is at mod_timer+0x210/0x250
>> [ 1227.766742] EAX: 00000000 EBX: f5494e1c ECX: 00000000 EDX: 00000000
>> [ 1227.766796] ESI: 00000000 EDI: 05348416 EBP: f54a3c90 ESP: f54a3c74
>> [ 1227.766851] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>> [ 1227.766904] Process mount (pid: 1507, ti=f54a2000 task=f2068880
>> task.ti=f54a2000)
>> [ 1227.767002] Stack:
>> [ 1227.767003] f2068880 f54b159c 00000010 00000000 f1f8e400 f4efc57c
>> 0000128d f54a3ca8
>> [ 1227.767003] c11cb7ba c17d4e52 f4efc400 00000124 00000000 f54a3cb4
>> c11ce4e6 ecee6318
>> [ 1227.767003] f54a3cdc c11cf7cc ecec7578 00000124 00000000 f4efc400
>> f54a3cd4 00000124
>> [ 1227.767003] Call Trace:
>> [ 1227.767003] [<c11cb7ba>] ? __save_error_info.clone.61+0x7a/0xf0
>> [ 1227.767003] [<c11ce4e6>] ? save_error_info+0x16/0x30
>> [ 1227.767003] [<c11cf7cc>] ? ext4_error_inode+0x4c/0xf0
>> [ 1227.767003] [<c11b57e1>] ? __ext4_get_inode_loc+0x201/0x410
>> [ 1227.767003] [<c110b62a>] ? inode_init_always+0x1aa/0x1c0
>> [ 1227.767003] [<c11b72f9>] ? ext4_iget+0x59/0x6f0
>> [ 1227.767003] [<c11d2716>] ? ext4_fill_super+0x1ab6/0x2c70
>> [ 1227.767003] [<c114896f>] ? disk_name+0xbf/0xd0
>> [ 1227.767003] [<c10fa119>] ? mount_bdev+0x179/0x1c0
>> [ 1227.767003] [<c11d0c60>] ? ext4_fill_super+0x0/0x2c70
>> [ 1227.767003] [<c11ca17f>] ? ext4_mount+0x1f/0x30
>> [ 1227.767003] [<c11d0c60>] ? ext4_fill_super+0x0/0x2c70
>> [ 1227.767003] [<c10f9835>] ? vfs_kern_mount+0x75/0x250
>> [ 1227.767003] [<c110df03>] ? get_fs_type+0x33/0xb0
>> [ 1227.767003] [<c11ca160>] ? ext4_mount+0x0/0x30
>> [ 1227.767003] [<c10f9a6e>] ? do_kern_mount+0x3e/0xe0
>> [ 1227.767003] [<c111080f>] ? do_mount+0x35f/0x6b0
>> [ 1227.767003] [<c10d47c9>] ? strndup_user+0x49/0x70
>> [ 1227.767003] [<c1110e0b>] ? sys_mount+0x6b/0xa0
>> [ 1227.767003] [<c17b550c>] ? syscall_call+0x7/0xb
>> [ 1227.767003] Code: fe ff ff 8b 0e 89 4d e4 8b 46 04 83 c6 08 89 f9 89 da
>> ff 55 e4 8b 06 85 c0 89 45 e4 75 ea e9 aa fe ff ff 8b 75 ec e9 ee fe ff ff
>> <0f> 0b 8b 55 04 89 d8 e8 34 f9 ff ff e9 2a fe ff ff 8b 35 30 b8
>> [ 1227.767003] EIP: [<c104f960>] mod_timer+0x210/0x250 SS:ESP
>> 0068:f54a3c74
>> [ 1227.770073] ---[ end trace d7b3d7a67954d202 ]---
>>
>>
>> which happens after:
>>
>> [ 1137.167043] Aborting journal on device md10-8.
>> [ 1137.167058] Buffer I/O error on device md10, logical block 139265
>> [ 1137.167060] lost page write due to I/O error on md10
>> [ 1137.167065] JBD2: I/O error detected when updating journal superblock
>> for md10-8.
>> [ 1137.660922] Buffer I/O error on device md10, logical block 1
>> [ 1137.660926] lost page write due to I/O error on md10
>> [ 1137.660932] EXT4-fs error (device md10): ext4_journal_start_sb:260:
>> Detected aborted journal
>> [ 1137.661046] EXT4-fs (md10): Remounting filesystem read-only
>> [ 1137.661103] EXT4-fs (md10): previous I/O error to superblock detected
>> [ 1137.661313] Buffer I/O error on device md10, logical block 1
>> [ 1137.661315] lost page write due to I/O error on md10
>> [ 1219.891363] EXT4-fs (md10): previous I/O error to superblock detected
>> [ 1220.050654] Buffer I/O error on device md10, logical block 1
>> [ 1220.050657] lost page write due to I/O error on md10
>> [ 1220.050663] EXT4-fs error (device md10): ext4_put_super:728: Couldn't
>> clean up the journal
>>
>> and some more "Buffer I/O error"s.
>>
>> So it looks like an ext4 issue.
>>
>> I have Cc:ed the appropriate list.
>>
>> Thanks for the report.
>>
>> NeilBrown
>>
>>
>
>
> --
> Darko Kraus
> Enterprise Network Administrator
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Best Wishes
Yongqiang Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] echo: fix octal escaping with \1...\7
From: Mike Frysinger @ 2011-10-31 4:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: dash
In-Reply-To: <20111031034146.GA19477@gondor.apana.org.au>
[-- Attachment #1: Type: Text/Plain, Size: 1975 bytes --]
On Sunday 30 October 2011 23:41:58 Herbert Xu wrote:
> Mike Frysinger wrote:
> > POSIX states that octal escape sequences should take the form \0num
> > when using echo. dash however additionally treats \num as an octal
> > sequence. This breaks some packages (like libtool) who attempt to
> > use strings with these escape sequences via variables to execute sed
> > (since sed ends up getting passed a byte instead of a literal \1).
>
> OK this is a bit of problem. From our conversation I had the
> impression that you were referring to the lack of support of
> escape codes, rather than unwanted support.
>
> If it was the former I could easily add it if POSIX said so,
> however, as this is an existing feature there may well be scripts
> out there that depend on it. So removing it is not an option
> unless it is explicitly forbidden by POSIX.
i'm not seeing how this jives with dash's goal. if it intends to be a
fast/small POSIX compliant shell while punting (almost) all the rest, then why
carry additional functionality that POSIX doesn't even mention in passing ?
this isn't "documented but optional extended functionality", but rather the
realm of "anything goes". otherwise we approach the same realm that dash was
created to avoid -- carrying lots of cruft that slow things down because
scripts use it rather than POSIX mandating it.
as a comparison, bash/ksh/tcsh/zsh/busybox[ash] all behave the way my patch
updates dash to operate ... i would test more shells, but these tend to be the
standards that everyone compares against. i can't see people writing scripts
that only work under dash either.
> In any case, scripts that rely on escape codes like this are
> simply broken and should either be fixed to use printf or just
> run with #!/bin/bash.
they're relying on these escape codes not being interpreted as escape codes
(which every other shell appears to do), not the other way around
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH V5 1/3] SDHCI: S3C: Use generic clock names for sdhci bus clock options
From: Rajeshwari Birje @ 2011-10-31 4:22 UTC (permalink / raw)
To: Chris Ball
Cc: Rajeshwari Shinde, linux-mmc, linux-samsung-soc, kgene.kim,
linux-arm-kernel
In-Reply-To: <m2obx34j81.fsf@bob.laptop.org>
Hi Chris,
Thank you for your comment will modify and resend the patches.
Regards,
Rajeshwari Shinde.
On Thu, Oct 27, 2011 at 1:29 AM, Chris Ball <cjb@laptop.org> wrote:
> Hi Rajeshwari, Kukjin,
>
> On Fri, Oct 14 2011, Rajeshwari Shinde wrote:
>> This patch modifies the driver to stop depending on the clock names
>> being passed from the platform and switch over to bus clock lookup
>> using generic clock names.
>>
>> Signed-off-by: Rajeshwari Shinde <rajeshwari.s@samsung.com>
>> ---
>> drivers/mmc/host/sdhci-s3c.c | 6 ++----
>> 1 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
>> index 82709b6..a5fde87 100644
>> --- a/drivers/mmc/host/sdhci-s3c.c
>> +++ b/drivers/mmc/host/sdhci-s3c.c
>> @@ -435,14 +435,12 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
>>
>> for (clks = 0, ptr = 0; ptr < MAX_BUS_CLK; ptr++) {
>> struct clk *clk;
>> - char *name = pdata->clocks[ptr];
>> + char name[14];
>>
>> - if (name == NULL)
>> - continue;
>> + sprintf(name, "mmc_busclk.%d", ptr);
>
> Let's use snprintf() here instead -- it's better to have fewer uses of
> sprintf() to audit.
>
>> clk = clk_get(dev, name);
>> if (IS_ERR(clk)) {
>> - dev_err(dev, "failed to get clock %s\n", name);
>> continue;
>> }
>
> Thanks,
>
> - Chris.
> --
> Chris Ball <cjb@laptop.org> <http://printf.net/>
> One Laptop Per Child
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH V5 1/3] SDHCI: S3C: Use generic clock names for sdhci bus clock options
From: Rajeshwari Birje @ 2011-10-31 4:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2obx34j81.fsf@bob.laptop.org>
Hi Chris,
Thank you for your comment will modify and resend the patches.
Regards,
Rajeshwari Shinde.
On Thu, Oct 27, 2011 at 1:29 AM, Chris Ball <cjb@laptop.org> wrote:
> Hi Rajeshwari, Kukjin,
>
> On Fri, Oct 14 2011, Rajeshwari Shinde wrote:
>> This patch modifies the driver to stop depending on the clock names
>> being passed from the platform and switch over to bus clock lookup
>> using generic clock names.
>>
>> Signed-off-by: Rajeshwari Shinde <rajeshwari.s@samsung.com>
>> ---
>> ?drivers/mmc/host/sdhci-s3c.c | ? ?6 ++----
>> ?1 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
>> index 82709b6..a5fde87 100644
>> --- a/drivers/mmc/host/sdhci-s3c.c
>> +++ b/drivers/mmc/host/sdhci-s3c.c
>> @@ -435,14 +435,12 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
>>
>> ? ? ? for (clks = 0, ptr = 0; ptr < MAX_BUS_CLK; ptr++) {
>> ? ? ? ? ? ? ? struct clk *clk;
>> - ? ? ? ? ? ? char *name = pdata->clocks[ptr];
>> + ? ? ? ? ? ? char name[14];
>>
>> - ? ? ? ? ? ? if (name == NULL)
>> - ? ? ? ? ? ? ? ? ? ? continue;
>> + ? ? ? ? ? ? sprintf(name, "mmc_busclk.%d", ptr);
>
> Let's use snprintf() here instead -- it's better to have fewer uses of
> sprintf() to audit.
>
>> ? ? ? ? ? ? ? clk = clk_get(dev, name);
>> ? ? ? ? ? ? ? if (IS_ERR(clk)) {
>> - ? ? ? ? ? ? ? ? ? ? dev_err(dev, "failed to get clock %s\n", name);
>> ? ? ? ? ? ? ? ? ? ? ? continue;
>> ? ? ? ? ? ? ? }
>
> Thanks,
>
> - Chris.
> --
> Chris Ball ? <cjb@laptop.org> ? <http://printf.net/>
> One Laptop Per Child
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [U-Boot] [PATCH] sh: Add a flag which controls the DDR ECC mode of sh7757lcr
From: Nobuhiro Iwamatsu @ 2011-10-31 4:22 UTC (permalink / raw)
To: u-boot
When DDR-ECC is effective, the physical memory which can be used
reduces this boardby half. However, this mode can chenge to disable.
When it was disabled, user can use 512 MB of physical memory.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
CC: "Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>
---
board/renesas/sh7757lcr/lowlevel_init.S | 3 ++-
include/configs/sh7757lcr.h | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/board/renesas/sh7757lcr/lowlevel_init.S b/board/renesas/sh7757lcr/lowlevel_init.S
index ab1aa49..5090fd0 100644
--- a/board/renesas/sh7757lcr/lowlevel_init.S
+++ b/board/renesas/sh7757lcr/lowlevel_init.S
@@ -326,12 +326,13 @@ PC_MASK: .long 0x20000000
/* step 26 */
wait_DBCMD
+#if defined(CONFIG_SH7757LCR_DDR_ECC)
/* enable DDR-ECC */
write32 ECD_ECDEN_A, ECD_ECDEN_D
write32 ECD_INTSR_A, ECD_INTSR_D
write32 ECD_SPACER_A, ECD_SPACER_D
write32 ECD_MCR_A, ECD_MCR_D
-
+#endif
bra exit_ddr
nop
diff --git a/include/configs/sh7757lcr.h b/include/configs/sh7757lcr.h
index 63b39d6..40fafc2 100644
--- a/include/configs/sh7757lcr.h
+++ b/include/configs/sh7757lcr.h
@@ -31,6 +31,7 @@
#define CONFIG_SH_32BIT 1
#define CONFIG_CPU_SH7757 1
#define CONFIG_SH7757LCR 1
+#define CONFIG_SH7757LCR_DDR_ECC 1
#define CONFIG_SYS_TEXT_BASE 0x8ef80000
#define CONFIG_SYS_LDSCRIPT "board/renesas/sh7757lcr/u-boot.lds"
--
1.7.6.3
^ permalink raw reply related
* Re: [PATCH 1/2] pch_dma: Support new device LAPIS Semiconductor ML7831 IOH
From: Vinod Koul @ 2011-10-31 4:18 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: Dan Williams, linux-kernel, qi.wang, yong.y.wang, joel.clark,
kok.howg.ewe
In-Reply-To: <1319761790-6882-1-git-send-email-tomoya-linux@dsn.lapis-semi.com>
On Fri, 2011-10-28 at 09:29 +0900, Tomoya MORINAGA wrote:
> ML7831 is companion chip for Intel Atom E6xx series.
>
> Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
> ---
> drivers/dma/Kconfig | 14 +++++++-------
> drivers/dma/pch_dma.c | 6 +++++-
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index ab8f469..22439e2 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -201,18 +201,18 @@ config PL330_DMA
> platform_data for a dma-pl330 device.
>
> config PCH_DMA
> - tristate "Intel EG20T PCH / OKI Semi IOH(ML7213/ML7223) DMA support"
> + tristate "Intel EG20T PCH / LAPIS Semicon IOH(ML7213/ML7223/ML7831) DMA"
Shouldn't this be in 2/2 where you are doing the name change
> depends on PCI && X86
> select DMA_ENGINE
> help
> Enable support for Intel EG20T PCH DMA engine.
>
> - This driver also can be used for OKI SEMICONDUCTOR IOH(Input/
> - Output Hub), ML7213 and ML7223.
> - ML7213 IOH is for IVI(In-Vehicle Infotainment) use and ML7223 IOH is
> - for MP(Media Phone) use.
> - ML7213/ML7223 is companion chip for Intel Atom E6xx series.
> - ML7213/ML7223 is completely compatible for Intel EG20T PCH.
> + This driver also can be used for LAPIS Semiconductor IOH(Input/
> + Output Hub), ML7213, ML7223 and ML7831.
> + ML7213 IOH is for IVI(In-Vehicle Infotainment) use, ML7223 IOH is
> + for MP(Media Phone) use and ML7831 IOH is for general purpose use.
> + ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
> + ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
>
> config IMX_SDMA
> tristate "i.MX SDMA support"
> diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
> index a6d0e3d..a46bedb 100644
> --- a/drivers/dma/pch_dma.c
> +++ b/drivers/dma/pch_dma.c
> @@ -1018,6 +1018,8 @@ static void __devexit pch_dma_remove(struct pci_dev *pdev)
> #define PCI_DEVICE_ID_ML7223_DMA2_4CH 0x800E
> #define PCI_DEVICE_ID_ML7223_DMA3_4CH 0x8017
> #define PCI_DEVICE_ID_ML7223_DMA4_4CH 0x803B
> +#define PCI_DEVICE_ID_ML7831_DMA1_8CH 0x8810
> +#define PCI_DEVICE_ID_ML7831_DMA2_4CH 0x8815
>
> DEFINE_PCI_DEVICE_TABLE(pch_dma_id_table) = {
> { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_8CH), 8 },
> @@ -1030,6 +1032,8 @@ DEFINE_PCI_DEVICE_TABLE(pch_dma_id_table) = {
> { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA2_4CH), 4}, /* Video SPI */
> { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA3_4CH), 4}, /* Security */
> { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA4_4CH), 4}, /* FPGA */
> + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA1_8CH), 8}, /* UART */
> + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA2_4CH), 4}, /* SPI */
> { 0, },
> };
>
> @@ -1057,7 +1061,7 @@ static void __exit pch_dma_exit(void)
> module_init(pch_dma_init);
> module_exit(pch_dma_exit);
>
> -MODULE_DESCRIPTION("Intel EG20T PCH / OKI SEMICONDUCTOR ML7213 IOH "
> +MODULE_DESCRIPTION("Intel EG20T PCH/OKI SEMICONDUCTOR ML7213/ML7223/ML7831 IOH "
> "DMA controller driver");
> MODULE_AUTHOR("Yong Wang <yong.y.wang@intel.com>");
> MODULE_LICENSE("GPL v2");
--
~Vinod
^ permalink raw reply
* Re: Patches for BTRFS (mail-server slow down in 3.0 and more)
From: Alexandre Oliva @ 2011-10-31 4:19 UTC (permalink / raw)
To: Chris Mason; +Cc: Marcel Lohmann, linux-btrfs
In-Reply-To: <20111029051206.GB4054@shiny.Mikenopa.local>
[-- Attachment #1: Type: text/plain, Size: 159 bytes --]
On Oct 29, 2011, Chris Mason <chris.mason@oracle.com> wrote:
> The last one isn't a bad idea, but please do make a real mount option
> for it ;)
Like this?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0004-Disable-clustered-allocation-with-o-nocluster.patch --]
[-- Type: text/x-diff, Size: 3058 bytes --]
>From af086e7b88637be5c9806181a1d70db9c645cb50 Mon Sep 17 00:00:00 2001
From: Alexandre Oliva <lxoliva@fsfla.org>
Date: Sat, 29 Oct 2011 02:20:55 -0200
Subject: [PATCH 4/4] Disable clustered allocation with -o nocluster
Introduce -o nocluster to disable the use of clusters for extent
allocation.
Signed-off-by: Alexandre Oliva <oliva@lsd.ic.unicamp.br>
---
fs/btrfs/ctree.h | 1 +
fs/btrfs/extent-tree.c | 2 +-
fs/btrfs/super.c | 11 +++++++++--
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 03912c5..b1138fb 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1363,6 +1363,7 @@ struct btrfs_ioctl_defrag_range_args {
#define BTRFS_MOUNT_ENOSPC_DEBUG (1 << 15)
#define BTRFS_MOUNT_AUTO_DEFRAG (1 << 16)
#define BTRFS_MOUNT_INODE_MAP_CACHE (1 << 17)
+#define BTRFS_MOUNT_NO_ALLOC_CLUSTER (1 << 18)
#define btrfs_clear_opt(o, opt) ((o) &= ~BTRFS_MOUNT_##opt)
#define btrfs_set_opt(o, opt) ((o) |= BTRFS_MOUNT_##opt)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index f5be06a..5d7c9a7 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4886,7 +4886,7 @@ static noinline int find_free_extent(struct btrfs_trans_handle *trans,
bool found_uncached_bg = false;
bool failed_cluster_refill = false;
bool failed_alloc = false;
- bool use_cluster = true;
+ bool use_cluster = !btrfs_test_opt(root, NO_ALLOC_CLUSTER);
u64 ideal_cache_percent = 0;
u64 ideal_cache_offset = 0;
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 15634d4..57c7bb1 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -162,7 +162,7 @@ enum {
Opt_notreelog, Opt_ratio, Opt_flushoncommit, Opt_discard,
Opt_space_cache, Opt_clear_cache, Opt_user_subvol_rm_allowed,
Opt_enospc_debug, Opt_subvolrootid, Opt_defrag,
- Opt_inode_cache, Opt_err,
+ Opt_inode_cache, Opt_nocluster, Opt_err,
};
static match_table_t tokens = {
@@ -195,6 +195,7 @@ static match_table_t tokens = {
{Opt_subvolrootid, "subvolrootid=%d"},
{Opt_defrag, "autodefrag"},
{Opt_inode_cache, "inode_cache"},
+ {Opt_nocluster, "nocluster"},
{Opt_err, NULL},
};
@@ -378,9 +379,13 @@ int btrfs_parse_options(struct btrfs_root *root, char *options)
btrfs_set_opt(info->mount_opt, ENOSPC_DEBUG);
break;
case Opt_defrag:
- printk(KERN_INFO "btrfs: enabling auto defrag");
+ printk(KERN_INFO "btrfs: enabling auto defrag\n");
btrfs_set_opt(info->mount_opt, AUTO_DEFRAG);
break;
+ case Opt_nocluster:
+ printk(KERN_INFO "btrfs: disabling alloc clustering\n");
+ btrfs_set_opt(info->mount_opt, NO_ALLOC_CLUSTER);
+ break;
case Opt_err:
printk(KERN_INFO "btrfs: unrecognized mount option "
"'%s'\n", p);
@@ -729,6 +734,8 @@ static int btrfs_show_options(struct seq_file *seq, struct vfsmount *vfs)
seq_puts(seq, ",autodefrag");
if (btrfs_test_opt(root, INODE_MAP_CACHE))
seq_puts(seq, ",inode_cache");
+ if (btrfs_test_opt(root, NO_ALLOC_CLUSTER))
+ seq_puts(seq, ",nocluster");
return 0;
}
--
1.7.4.4
[-- Attachment #3: Type: text/plain, Size: 258 bytes --]
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
^ permalink raw reply related
* Re: Unable to mount btrfs partition
From: dima @ 2011-10-31 4:19 UTC (permalink / raw)
To: email; +Cc: linux-btrfs
In-Reply-To: <df08964cfb0f7e20f039e7fdbb970f35@joachim-neu.de>
On 10/29/2011 08:45 AM, email@joachim-neu.de wrote:
>
> On Fri, 28 Oct 2011 22:09:47 +0100, Hugo Mills <hugo@carfax.org.uk> wrote:
>> On Fri, Oct 28, 2011 at 08:36:28PM +0000, email@joachim-neu.de wrote:
>>> Today I downgraded from Ubuntu's APT repo "oneiric-proposed" (which
>>> brings some kernel 3.0.0-13) back to the standard repo "oneiric".
>>
>> It's odd that switching from one 3.0.0 to another would cause
>> something bad to happen. Did something else happen in the process,
>> like a reboot without a clean shutdown? (This includes power loss,
>> suspend and failure to resume, and Alt-SysRq-b).
>
> I agree, but there was no power loss or anything. Maybe the fs didn't
> unmount correctly or fast enough when rebooting?
>
>>> Now I'm not able to mount my btrfs / and /home (both on the same
>>> partition) anymore:
>>>
>>> device fsid SOME-UUID devid 1 transid 84229 /dev/dm-0
>>> parent transid verify failed on 77078528 wanted 83774 found 84226
>>> parent transid verify failed on 77078528 wanted 83774 found 84226
>>> parent transid verify failed on 77078528 wanted 83774 found 84226
>>> parent transid verify failed on 77078528 wanted 83774 found 84226
>>> btrfs: open_ctree failed
>>>
>>> The boot process drops to the initramfs shell with no btrfsck
>>> available.
>>
>> It wouldn't make any difference if it were -- btrfsck doesn't
>> actually fix anything, I'm afraid. This error message is regrettably
>> generic, and covers a whole range of evils. It's possible that 3.1 may
>> be able to deal swith the breakage ufficiently well to allow you to
>> boot and copy your files.
>
> I'll give the 3.1 kernel a try right after "restore" finished which is
> running right now and doing quite a good job so far (as far as my / is
> concerned, lets wait for the /home).
You should definitely try 3.1. There are many improvements for btrfs.
What errors are you getting on the screen and in your logs when you try
to mount your subvolumes manually when booting from a live CD? Are / and
/home in different subvolumes by the way?
> What do the above error messages indicate?
Try to google it. It looks like pretty common error that can be caused
by a bunch of things as Hugo mentioned.
> Is there an incrementing
> number for every transaction and the number of the most recent
> transaction is stored somewhere and those messages occur once those
> numbers are out of sync somehow? Is it possible to "just" discard the
> last transactions? I would not mind, better loose a day than a month...
> Why is the message there three times? Is this information stored in a
> couple of backups? If so: can't I use any of the other backups
> temporarily? "restore" opens the fs in a ro recovery mode somehow where
> it ignores those errors. Is it possible to "force" the btrfs driver to
> load the fs in this recovery mode as readonly, too?
I don't think anything of this is possible.
~d
^ permalink raw reply
* Re: [PATCH] document 'T' status from git-status
From: Junio C Hamano @ 2011-10-31 4:18 UTC (permalink / raw)
To: Mark Dominus; +Cc: git, Mark Dominus
In-Reply-To: <4EADB4DB.5020004@icgroup.com>
Mark Dominus <mjd@icgroup.com> writes:
>> The current organization of this table may need to be rethought, but if we
>> were to keep it, then this change is far from sufficient. For example, you
>> do not explain what XY = TT means.
> Thanks for your response.
>
> I did not try to document that because in my experimenting I was not
> able to produce that situation.
It is trivial if you realize that X is the change between the HEAD and the
index, and Y is the change between the index and the working tree. Most
importantly, no direct comparison between the HEAD and the working tree
gets in the picture.
$ mv COPYING RENAMING
$ ln -s RENAMING COPYING
$ git add COPYING
$ mv RENAMING COPYING
$ git status -suno
TT COPYING
> Will you be applying the alternative patch you suggested, or would you
> prefer that I try to produce one along those lines?
I dunno.
An obvious alternative is to add T next to all occurrences of M in the
table where we say "M is possible", but unless it is accompanied by an
explanation "T is just a special case of M", I suspect the resulting
description would be harder to understand than currently is, and as long
as the reader understands "T is just a special case of M", then there
isn't much point adding T everywhere M appears in the table anyway, so...
^ permalink raw reply
* Re: [PATCH 09/36] m68k: set register a2 to current if MMU enabled on ColdFire
From: Greg Ungerer @ 2011-10-31 4:19 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, uclinux-dev, Greg Ungerer
In-Reply-To: <CAMuHMdWU-W9jDYs4KMRvyB7uxs2gKS7_FEz6QQr1jDxWY2xPKQ@mail.gmail.com>
Hi Geert,
On 30/10/11 23:06, Geert Uytterhoeven wrote:
> On Tue, Oct 25, 2011 at 09:19,<gerg@snapgear.com> wrote:
>> From: Greg Ungerer<gerg@uclinux.org>
>>
>> Virtual memory m68k systems build with register a2 dedicated to being the
>> current proc pointer. Add code to the ColdFire interrupt and exception
>> processing to set this on entry, and also at context switch time.
>>
>> Signed-off-by: Greg Ungerer<gerg@uclinux.org>
>> ---
>> arch/m68k/kernel/entry_no.S 24 ++++++++++++++++++------
>> arch/m68k/platform/coldfire/entry.S | 18 +++++++++++++++++-
>> 2 files changed, 35 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/m68k/kernel/entry_no.S b/arch/m68k/kernel/entry_no.S
>> index 1b42890..050d7ea 100644
>> --- a/arch/m68k/kernel/entry_no.S
>> +++ b/arch/m68k/kernel/entry_no.S
>> @@ -44,8 +44,12 @@
>>
>> ENTRY(buserr)
>> SAVE_ALL_INT
>> - moveq #-1,%d0
>> - movel %d0,%sp@(PT_OFF_ORIG_D0)
>
> Don't you need the above anymore, at least on nommu?
Yes it is needed, but it is done in the SAVE_ALL_INT macro now.
That was done in commit 61619b12078dc8b85a3d4cbfa16f650daa341bd1
("m68k: merge mmu and non-mmu include/asm/entry.h files").
It sure has nothing to do with the a2 work that the patch description
says above :) I'll move this change into a separate patch with
appropriate comments.
Regards
Greg
>> +#ifdef CONFIG_MMU
>> + á á á movel á %sp,%d0 á á á á á á á á /* get thread_info pointer */
>> + á á á andl á á#-THREAD_SIZE,%d0 á á á /* at start of kernel stack */
>> + á á á movel á %d0,%a2
>> + á á á movel á %a2@,%a2 á á á á á á á á/* current pointer into a2 */
>> +#endif
>> á á á ámovel á %sp,%sp@- á á á á á á á /* stack frame pointer argument */
>> á á á ájsr á á buserr_c
>> á á á áaddql á #4,%sp
>> @@ -53,8 +57,12 @@ ENTRY(buserr)
>>
>> áENTRY(trap)
>> á á á áSAVE_ALL_INT
>> - á á á moveq á #-1,%d0
>> - á á á movel á %d0,%sp@(PT_OFF_ORIG_D0)
>
> Same here.
>
>> +#ifdef CONFIG_MMU
>> + á á á movel á %sp,%d0 á á á á á á á á /* get thread_info pointer */
>> + á á á andl á á#-THREAD_SIZE,%d0 á á á /* at start of kernel stack */
>> + á á á movel á %d0,%a2
>> + á á á movel á %a2@,%a2 á á á á á á á á/* current pointer into a2 */
>> +#endif
>> á á á ámovel á %sp,%sp@- á á á á á á á /* stack frame pointer argument */
>> á á á ájsr á á trap_c
>> á á á áaddql á #4,%sp
>> @@ -65,8 +73,12 @@ ENTRY(trap)
>> á.globl dbginterrupt
>> áENTRY(dbginterrupt)
>> á á á áSAVE_ALL_INT
>> - á á á moveq á #-1,%d0
>> - á á á movel á %d0,%sp@(PT_OFF_ORIG_D0)
>> +#ifdef CONFIG_MMU
>> + á á á movel á %sp,%d0 á á á á á á á á /* get thread_info pointer */
>> + á á á andl á á#-THREAD_SIZE,%d0 á á á /* at start of kernel stack */
>> + á á á movel á %d0,%a2
>> + á á á movel á %a2@,%a2 á á á á á á á á/* current pointer into a2 */
>> +#endif
>> á á á ámovel á %sp,%sp@- á á á á á á á /* stack frame pointer argument */
>> á á á ájsr á á dbginterrupt_c
>> á á á áaddql á #4,%sp
>> diff --git a/arch/m68k/platform/coldfire/entry.S b/arch/m68k/platform/coldfire/entry.S
>> index f567a16..5fc1f40 100644
>> --- a/arch/m68k/platform/coldfire/entry.S
>> +++ b/arch/m68k/platform/coldfire/entry.S
>> @@ -63,6 +63,13 @@ ENTRY(system_call)
>> á á á áSAVE_ALL_SYS
>> á á á ámove á á#0x2000,%sr á á á á á á /* enable intrs again */
>>
>> +#ifdef CONFIG_MMU
>> + á á á movel á %sp,%d2 á á á á á á á á /* get thread_info pointer */
>> + á á á andl á á#-THREAD_SIZE,%d2 á á á /* at start of kernel stack */
>> + á á á movel á %d2,%a2
>> + á á á movel á %a2@,%a2 á á á á á á á á/* current pointer into a2 */
>> +#endif
>> +
>> á á á ácmpl á á#NR_syscalls,%d0
>> á á á ájcc á á enosys
>> á á á álea á á sys_call_table,%a0
>> @@ -166,6 +173,13 @@ Lsignal_return:
>> áENTRY(inthandler)
>> á á á áSAVE_ALL_INT
>>
>> +#ifdef CONFIG_MMU
>> + á á á movel á %sp,%d2 á á á á á á á á /* get thread_info pointer */
>> + á á á andl á á#-THREAD_SIZE,%d2 á á á /* at start of kernel stack */
>> + á á á movel á %d2,%a2
>> + á á á movel á %a2@,%a2 á á á á á á á á/* current pointer into a2 */
>> +#endif
>> +
>> á á á ámovew á %sp@(PT_OFF_FORMATVEC),%d0 /* put exception # in d0 */
>> á á á áandl á á#0x03fc,%d0 á á á á á á /* mask out vector only */
>>
>> @@ -190,7 +204,9 @@ ENTRY(resume)
>> á á á ámovel á %sp,%a0@(TASK_THREAD+THREAD_KSP) /* save kernel stack pointer */
>> á á á áRDUSP á á á á á á á á á á á á á á á á á á/* movel %usp,%a3 */
>> á á á ámovel á %a3,%a0@(TASK_THREAD+THREAD_USP) /* save thread user stack */
>> -
>> +#ifdef CONFIG_MMU
>> + á á á movel á %a1,%a2 á á á á á á á á á á á á á/* set new current */
>> +#endif
>> á á á ámovel á %a1@(TASK_THREAD+THREAD_USP),%a3 /* restore thread user stack */
>> á á á áWRUSP á á á á á á á á á á á á á á á á á á/* movel %a3,%usp */
>> á á á ámovel á %a1@(TASK_THREAD+THREAD_KSP),%sp /* restore new kernel stack */
>
> Gr{oetje,eeting}s,
>
> á á á á á á á á á á á á Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> á á á á á á á á á á á á á áá áá -- Linus Torvalds
>
>
>
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 3/3] monitor: add ability to dump SLB entries
From: David Gibson @ 2011-10-31 4:14 UTC (permalink / raw)
To: Alexander Graf; +Cc: Nishanth Aravamudan, qemu-ppc, qemu-devel
In-Reply-To: <3CCDA61A-2DAE-416F-879B-ABE3104EED2B@suse.de>
Good points below. I forgot to CC Nish, the original patch author on
my post, so I've added him to the list now.
Nish, can you correct these problems and resend the patch please?
On Mon, Oct 31, 2011 at 04:35:54AM +0100, Alexander Graf wrote:
>
> On 31.10.2011, at 04:16, David Gibson wrote:
>
> > From: Nishanth Aravamudan <nacc@us.ibm.com>
> >
> > When run with a PPC Book3S (server) CPU Currently 'info tlb' in the
> > qemu monitor reports "dump_mmu: unimplemented". However, during
> > bringup work, it can be quite handy to have the SLB entries, which are
> > available in the CPUPPCState. This patch adds an implementation of
> > info tlb for book3s, which dumps the SLB.
> >
> > Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> > target-ppc/helper.c | 32 +++++++++++++++++++++++++++-----
> > 1 files changed, 27 insertions(+), 5 deletions(-)
> >
> > diff --git a/target-ppc/helper.c b/target-ppc/helper.c
> > index 137a494..29c7050 100644
> > --- a/target-ppc/helper.c
> > +++ b/target-ppc/helper.c
> > @@ -1545,14 +1545,36 @@ static void mmubooke206_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
> > }
> > }
> >
> > +static void mmubooks_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
> > + CPUState *env)
> > +{
> > + int i;
> > + uint64_t slbe, slbv;
> > +
> > + cpu_synchronize_state(env);
> > +
> > + cpu_fprintf(f, "SLB\tESID\t\t\tVSID\n");
> > + for (i = 0; i < env->slb_nr; i++) {
> > + slbe = env->slb[i].esid;
> > + slbv = env->slb[i].vsid;
>
> From cpu.h:
>
> #if defined(TARGET_PPC64)
> /* Address space register */
> target_ulong asr;
> /* PowerPC 64 SLB area */
> ppc_slb_t slb[64];
> int slb_nr;
> #endif
>
>
> > + if (slbe == 0 && slbv == 0) {
> > + continue;
> > + }
> > + cpu_fprintf(f, "%d\t0x%016" PRIx64 "\t0x%016" PRIx64 "\n",
> > + i, slbe, slbv);
> > + }
> > +}
> > +
> > void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env)
> > {
> > - switch (env->mmu_model) {
> > - case POWERPC_MMU_BOOKE206:
> > + if (env->mmu_model == POWERPC_MMU_BOOKE206) {
> > mmubooke206_dump_mmu(f, cpu_fprintf, env);
> > - break;
> > - default:
> > - cpu_fprintf(f, "%s: unimplemented\n", __func__);
> > + } else {
> > + if ((env->mmu_model & POWERPC_MMU_64B) != 0) {
>
> I would actually prefer to explicitly keep the switch and match on all implementations explicitly. Also, have you verified this works without CONFIG_PPC64 set? In cpu.h I see the following:
>
> #if defined(TARGET_PPC64)
> #define POWERPC_MMU_64 0x00010000
> #define POWERPC_MMU_1TSEG 0x00020000
> /* 64 bits PowerPC MMU */
> POWERPC_MMU_64B = POWERPC_MMU_64 | 0x00000001,
> /* 620 variant (no segment exceptions) */
> POWERPC_MMU_620 = POWERPC_MMU_64 | 0x00000002,
> /* Architecture 2.06 variant */
> POWERPC_MMU_2_06 = POWERPC_MMU_64 | POWERPC_MMU_1TSEG | 0x00000003,
> #endif /* defined(TARGET_PPC64) */
>
> So POWERPC_MMU_64B shouldn't be defined for qemu-system-ppc.
>
>
> Alex
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Crypto Update for 3.2
From: Herbert Xu @ 2011-10-31 4:09 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20110724011752.GA14373@gondor.apana.org.au>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Linus:
Here is the crypto update for 3.2:
* User-space interface for algorithm selection/configuration
* SSSE3 implementation of SHA1.
* X86-64 assembly implementation of blowfish.
* X86-64 assembly implementation of twofish.
* Misc fixes.
Please pull from
git://github.com/herbertx/crypto.git
The top commit object is
commit ea8bdfcff17599e5d80f93e2ae194fbbab7f8d5e
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed Oct 26 17:15:10 2011 +0200
crypto: user - Add dependency on NET
Alexey Dobriyan (1):
crypto: whirlpool - count rounds from 0
H Hartley Sweeten (1):
crypto: aes-x86 - quiet sparse noise about symbol not declared
Herbert Xu (4):
crypto: sha - Fix build error due to crypto_sha1_update
crypto: cryptd - Use subsys_initcall to prevent races with aesni
crypto: user - Initialise match in crypto_alg_match
crypto: user - Add dependency on NET
Jamie Iles (5):
crypto: picoxcell - convert to platform ID table
crypto: picoxcell - add connection ID to the clock name
crypto: picoxcell - support for device tree matching
crypto: picoxcell - fix possible invalid pointer dereference
crypto: picoxcell - add dependency on HAVE_CLK
Jonathan Nieder (1):
crypto: padlock-aes - Make module loading even quieter when hardware is missing
Jussi Kivilinna (13):
crypto: blowfish - split generic and common c code
crypto: blowfish - rename C-version to blowfish_generic
crypto: tcrypt - add ctr(blowfish) speed test
crypto: blowfish - add x86_64 assembly implementation
crypto: blowfish-x86_64 - improve x86_64 blowfish 4-way performance
crypto: blowfish-x86_64 - add credits
crypto: tcrypt - add ctr(twofish) speed test
crypto: twofish-x86-asm - make assembler functions use twofish_ctx instead of crypto_tfm
crypto: twofish - add 3-way parallel x86_64 assembler implemention
crypto: blowfish-x86_64 - fix ctr blocksize to 1
crypto: twofish-x86_64-3way - fix ctr blocksize to 1
crypto: testmgr - add blowfish test-vectors
crypto: testmgr - add twofish tests
Kim Phillips (1):
crypto: talitos - handle descriptor not found in error path
Mathias Krause (2):
crypto: sha1 - export sha1_update for reuse
crypto: sha1 - SSSE3 based SHA1 implementation for x86-64
Richard Weinberger (1):
crypto: Make hifn_795x build depend on !ARCH_DMA_ADDR_T_64BIT
Steffen Klassert (17):
crypto: Add a flag to identify crypto instances
crypto: Export crypto_remove_spawns
crypto: Export crypto_remove_final
crypto: Add userspace configuration API
crypto: Add a report function pointer to crypto_type
crypto: Add userspace report for larval type algorithms
crypto: Add userspace report for shash type algorithms
crypto: Add userspace report for ahash type algorithms
crypto: Add userspace report for blkcipher type algorithms
crypto: Add userspace report for ablkcipher type algorithms
crypto: Add userspace report for givcipher type algorithms
crypto: Add userspace report for aead type algorithms
crypto: Add userspace report for nivaead type algorithms
crypto: Add userspace report for pcompress type algorithms
crypto: Add userspace report for rng type algorithms
crypto: Add userspace report for cipher type algorithms
crypto: Add userspace report for compress type algorithms
Thomas Meyer (1):
crypto: n2 - Fix a get/put_cpu() imbalance
.../devicetree/bindings/crypto/picochip-spacc.txt | 23 +
arch/x86/crypto/Makefile | 12 +
arch/x86/crypto/aes_glue.c | 1 +
arch/x86/crypto/blowfish-x86_64-asm_64.S | 390 ++++++++++++++
arch/x86/crypto/blowfish_glue.c | 492 +++++++++++++++++
arch/x86/crypto/sha1_ssse3_asm.S | 558 ++++++++++++++++++++
arch/x86/crypto/sha1_ssse3_glue.c | 240 +++++++++
arch/x86/crypto/twofish-i586-asm_32.S | 10 +-
arch/x86/crypto/twofish-x86_64-asm_64-3way.S | 316 +++++++++++
arch/x86/crypto/twofish-x86_64-asm_64.S | 6 +-
arch/x86/crypto/twofish_glue.c | 12 +-
arch/x86/crypto/twofish_glue_3way.c | 472 +++++++++++++++++
arch/x86/include/asm/cpufeature.h | 3 +
crypto/Kconfig | 63 +++
crypto/Makefile | 4 +-
crypto/ablkcipher.c | 48 ++
crypto/aead.c | 48 ++
crypto/ahash.c | 21 +
crypto/algapi.c | 12 +-
crypto/blkcipher.c | 25 +
crypto/{blowfish.c => blowfish_common.c} | 98 +----
crypto/blowfish_generic.c | 142 +++++
crypto/cryptd.c | 2 +-
crypto/crypto_user.c | 438 +++++++++++++++
crypto/internal.h | 3 +
crypto/pcompress.c | 18 +
crypto/rng.c | 20 +
crypto/sha1_generic.c | 9 +-
crypto/shash.c | 21 +
crypto/tcrypt.c | 10 +
crypto/testmgr.c | 30 +
crypto/testmgr.h | 398 ++++++++++++++-
crypto/wp512.c | 18 +-
drivers/crypto/Kconfig | 3 +-
drivers/crypto/hifn_795x.c | 6 +-
drivers/crypto/n2_core.c | 4 +-
drivers/crypto/padlock-aes.c | 4 +-
drivers/crypto/picoxcell_crypto.c | 121 ++---
drivers/crypto/talitos.c | 18 +-
include/crypto/algapi.h | 2 +
include/crypto/blowfish.h | 23 +
include/crypto/sha.h | 5 +
include/linux/crypto.h | 5 +
include/linux/cryptouser.h | 102 ++++
include/linux/netlink.h | 1 +
45 files changed, 4049 insertions(+), 208 deletions(-)
Thanks,
- --
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIVAwUBTq4fYccnHQpJsYunAQJZrQ/9E5MI/nKrm2onn+OMY1+4h45X9diVPDVx
0Aq1swHrZ5zase3BTW2T1sIOLVgtP1Nma7xogZVkauI92QI3O0W74QebV+y/lSWf
WRewZsTS2S7QAsZRiu8S6sgp2GfgksWuvhI0KiJ0F5YUi2RRR/DUNMDESIlaHvvR
dHkkwhsw7DAIimPdalfubo1KPBcQNGKujuPSQ3kw7k/CrRe8up70KKn5LcQ/Ktqv
Q5/HBKDDRPxHcAA9jQDDVbvHLKUnMrUKKITOn2+qds+qTbZEQxECzRAIIyHsc83r
qnQZJD/1kJney1Xi8U8SXSfOMMjn1xWnH9/+fx7id9zIsSqC730zoTCnRO/XQ9nz
Fv0STsfa3lZEDCtpB9ngcrWD6IKPNS0vLmNb1BV0QqRxf+fQUaDPUCSc0dMK4BgA
FlUt/QKosNs8BtDgLmt2iV+CSMs4aHDX/DAW8Kg2O0jJ8eGw0/Mu4v0aWNq6SNFe
Fc3AGgLfDv7QXkVzOmUTjJLl6BzlB3gD72da22/i4Ca4m6sn7KHKhXF/0MRTLD+k
RG78GFfZnSxIcB/QUGOZ5U5ddJ38w840roYuP58bw1tkk9tcQ9+OZMBRwImc4Xdb
5KD39QDGzUG/TFYNsKquIt+ay0g7A/f5Q9gT2eSHIo/xyvojlRMVZCUmDBaoNCCG
McFKjcup+LI=
=PElH
-----END PGP SIGNATURE-----
^ permalink raw reply
* Crypto Update for 3.2
From: Herbert Xu @ 2011-10-31 4:09 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List <linux-cry
In-Reply-To: <20110724011752.GA14373@gondor.apana.org.au>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Linus:
Here is the crypto update for 3.2:
* User-space interface for algorithm selection/configuration
* SSSE3 implementation of SHA1.
* X86-64 assembly implementation of blowfish.
* X86-64 assembly implementation of twofish.
* Misc fixes.
Please pull from
git://github.com/herbertx/crypto.git
The top commit object is
commit ea8bdfcff17599e5d80f93e2ae194fbbab7f8d5e
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed Oct 26 17:15:10 2011 +0200
crypto: user - Add dependency on NET
Alexey Dobriyan (1):
crypto: whirlpool - count rounds from 0
H Hartley Sweeten (1):
crypto: aes-x86 - quiet sparse noise about symbol not declared
Herbert Xu (4):
crypto: sha - Fix build error due to crypto_sha1_update
crypto: cryptd - Use subsys_initcall to prevent races with aesni
crypto: user - Initialise match in crypto_alg_match
crypto: user - Add dependency on NET
Jamie Iles (5):
crypto: picoxcell - convert to platform ID table
crypto: picoxcell - add connection ID to the clock name
crypto: picoxcell - support for device tree matching
crypto: picoxcell - fix possible invalid pointer dereference
crypto: picoxcell - add dependency on HAVE_CLK
Jonathan Nieder (1):
crypto: padlock-aes - Make module loading even quieter when hardware is missing
Jussi Kivilinna (13):
crypto: blowfish - split generic and common c code
crypto: blowfish - rename C-version to blowfish_generic
crypto: tcrypt - add ctr(blowfish) speed test
crypto: blowfish - add x86_64 assembly implementation
crypto: blowfish-x86_64 - improve x86_64 blowfish 4-way performance
crypto: blowfish-x86_64 - add credits
crypto: tcrypt - add ctr(twofish) speed test
crypto: twofish-x86-asm - make assembler functions use twofish_ctx instead of crypto_tfm
crypto: twofish - add 3-way parallel x86_64 assembler implemention
crypto: blowfish-x86_64 - fix ctr blocksize to 1
crypto: twofish-x86_64-3way - fix ctr blocksize to 1
crypto: testmgr - add blowfish test-vectors
crypto: testmgr - add twofish tests
Kim Phillips (1):
crypto: talitos - handle descriptor not found in error path
Mathias Krause (2):
crypto: sha1 - export sha1_update for reuse
crypto: sha1 - SSSE3 based SHA1 implementation for x86-64
Richard Weinberger (1):
crypto: Make hifn_795x build depend on !ARCH_DMA_ADDR_T_64BIT
Steffen Klassert (17):
crypto: Add a flag to identify crypto instances
crypto: Export crypto_remove_spawns
crypto: Export crypto_remove_final
crypto: Add userspace configuration API
crypto: Add a report function pointer to crypto_type
crypto: Add userspace report for larval type algorithms
crypto: Add userspace report for shash type algorithms
crypto: Add userspace report for ahash type algorithms
crypto: Add userspace report for blkcipher type algorithms
crypto: Add userspace report for ablkcipher type algorithms
crypto: Add userspace report for givcipher type algorithms
crypto: Add userspace report for aead type algorithms
crypto: Add userspace report for nivaead type algorithms
crypto: Add userspace report for pcompress type algorithms
crypto: Add userspace report for rng type algorithms
crypto: Add userspace report for cipher type algorithms
crypto: Add userspace report for compress type algorithms
Thomas Meyer (1):
crypto: n2 - Fix a get/put_cpu() imbalance
.../devicetree/bindings/crypto/picochip-spacc.txt | 23 +
arch/x86/crypto/Makefile | 12 +
arch/x86/crypto/aes_glue.c | 1 +
arch/x86/crypto/blowfish-x86_64-asm_64.S | 390 ++++++++++++++
arch/x86/crypto/blowfish_glue.c | 492 +++++++++++++++++
arch/x86/crypto/sha1_ssse3_asm.S | 558 ++++++++++++++++++++
arch/x86/crypto/sha1_ssse3_glue.c | 240 +++++++++
arch/x86/crypto/twofish-i586-asm_32.S | 10 +-
arch/x86/crypto/twofish-x86_64-asm_64-3way.S | 316 +++++++++++
arch/x86/crypto/twofish-x86_64-asm_64.S | 6 +-
arch/x86/crypto/twofish_glue.c | 12 +-
arch/x86/crypto/twofish_glue_3way.c | 472 +++++++++++++++++
arch/x86/include/asm/cpufeature.h | 3 +
crypto/Kconfig | 63 +++
crypto/Makefile | 4 +-
crypto/ablkcipher.c | 48 ++
crypto/aead.c | 48 ++
crypto/ahash.c | 21 +
crypto/algapi.c | 12 +-
crypto/blkcipher.c | 25 +
crypto/{blowfish.c => blowfish_common.c} | 98 +----
crypto/blowfish_generic.c | 142 +++++
crypto/cryptd.c | 2 +-
crypto/crypto_user.c | 438 +++++++++++++++
crypto/internal.h | 3 +
crypto/pcompress.c | 18 +
crypto/rng.c | 20 +
crypto/sha1_generic.c | 9 +-
crypto/shash.c | 21 +
crypto/tcrypt.c | 10 +
crypto/testmgr.c | 30 +
crypto/testmgr.h | 398 ++++++++++++++-
crypto/wp512.c | 18 +-
drivers/crypto/Kconfig | 3 +-
drivers/crypto/hifn_795x.c | 6 +-
drivers/crypto/n2_core.c | 4 +-
drivers/crypto/padlock-aes.c | 4 +-
drivers/crypto/picoxcell_crypto.c | 121 ++---
drivers/crypto/talitos.c | 18 +-
include/crypto/algapi.h | 2 +
include/crypto/blowfish.h | 23 +
include/crypto/sha.h | 5 +
include/linux/crypto.h | 5 +
include/linux/cryptouser.h | 102 ++++
include/linux/netlink.h | 1 +
45 files changed, 4049 insertions(+), 208 deletions(-)
Thanks,
- --
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIVAwUBTq4fYccnHQpJsYunAQJZrQ/9E5MI/nKrm2onn+OMY1+4h45X9diVPDVx
0Aq1swHrZ5zase3BTW2T1sIOLVgtP1Nma7xogZVkauI92QI3O0W74QebV+y/lSWf
WRewZsTS2S7QAsZRiu8S6sgp2GfgksWuvhI0KiJ0F5YUi2RRR/DUNMDESIlaHvvR
dHkkwhsw7DAIimPdalfubo1KPBcQNGKujuPSQ3kw7k/CrRe8up70KKn5LcQ/Ktqv
Q5/HBKDDRPxHcAA9jQDDVbvHLKUnMrUKKITOn2+qds+qTbZEQxECzRAIIyHsc83r
qnQZJD/1kJney1Xi8U8SXSfOMMjn1xWnH9/+fx7id9zIsSqC730zoTCnRO/XQ9nz
Fv0STsfa3lZEDCtpB9ngcrWD6IKPNS0vLmNb1BV0QqRxf+fQUaDPUCSc0dMK4BgA
FlUt/QKosNs8BtDgLmt2iV+CSMs4aHDX/DAW8Kg2O0jJ8eGw0/Mu4v0aWNq6SNFe
Fc3AGgLfDv7QXkVzOmUTjJLl6BzlB3gD72da22/i4Ca4m6sn7KHKhXF/0MRTLD+k
RG78GFfZnSxIcB/QUGOZ5U5ddJ38w840roYuP58bw1tkk9tcQ9+OZMBRwImc4Xdb
5KD39QDGzUG/TFYNsKquIt+ay0g7A/f5Q9gT2eSHIo/xyvojlRMVZCUmDBaoNCCG
McFKjcup+LI=
=PElH
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: ping_pong test of ceph
From: Gregory Farnum @ 2011-10-31 4:07 UTC (permalink / raw)
To: mowang da; +Cc: ceph-devel
In-Reply-To: <CAMwsgzM5O1Xx+5WdufJdSUj1g500X36D0mtJizWF+aOSg4vr_w@mail.gmail.com>
Not unless you want to hack the code to remove its flock
implementation. I'm not sure why you'd want to, though -- flock is
unlikely to be in the critical path for applications.
(If it is important, you can also use the userspace client -- unlike
the kernel client, it doesn't yet implement distributed flock.)
On Sun, Oct 30, 2011 at 7:18 PM, mowang da <whooya.xxl@gmail.com> wrote:
> thanks , if there is only one client, can we use local flock to
> replace flock mds?
>
> 2011/10/31 Gregory Farnum <gregory.farnum@dreamhost.com>:
>> On Sun, Oct 30, 2011 at 6:21 PM, mowang da <whooya.xxl@gmail.com> wrote:
>>> hi all,
>>> this bug has been fixed yet? i can't find any information of it.
>>> thanks for your help.
>>
>> Yes, it was fixed a while ago in our master branch and is fixed in our
>> last couple of releases. (Our newest is v0.37.)
>> As the problem was in the MDS server, to see this fix you only need to
>> upgrade the userspace packages. :)
>> -Greg
>>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-devel] [PULL 00/22] ppc patch queue 2011-10-30
From: Alexander Graf @ 2011-10-31 4:03 UTC (permalink / raw)
To: Alexander Graf; +Cc: Blue Swirl, qemu-ppc, qemu-devel
In-Reply-To: <1320006193-15219-1-git-send-email-agraf@suse.de>
On 30.10.2011, at 21:22, Alexander Graf wrote:
> Hi Blue,
>
> This is my current patch queue for ppc. Please pull.
>
> Alex
>
>
> The following changes since commit 375847a6c0330e3de0fd1589eeb5a364692b791e:
> Max Filippov (1):
> MAINTAINERS: update wiki URL and machine names for target-xtensa
>
> are available in the git repository at:
>
> git://repo.or.cz/qemu/agraf.git ppc-next
>
> Alexander Graf (4):
> PPC: Bump qemu-system-ppc to 64-bit physical address space
> PPC: Disable non-440 CPUs for ppcemb target
> PPC: Fail configure when libfdt is not available
> KVM: PPC: Override host vmx/vsx/dfp only when information known
>
> David Gibson (15):
> pseries: Support SMT systems for KVM Book3S-HV
> pseries: Allow KVM Book3S-HV on PPC970 CPUS
> pseries: Use Book3S-HV TCE acceleration capabilities
> pseries: Update SLOF firmware image
> ppc: Generalize the kvmppc_get_clockfreq() function
> pseries: Add device tree properties for VMX/VSX and DFP under kvm
> pseries: Update SLOF firmware image
> ppc: Remove broken partial PVR matching
> ppc: First cut implementation of -cpu host
> ppc: Add cpu defs for POWER7 revisions 2.1 and 2.3
> pseries: Under kvm use guest cpu = host cpu by default
> ppc: Avoid decrementer related kvm exits
> pseries: Correct vmx/dfp handling in both KVM and TCG cases
> ppc: Fix up usermode only builds
> pseries: Allow writes to KVM accelerated TCE table
I added these patches in between as well:
ppc: Alter CPU state to mask out TCG unimplemented instructions as appropriate
pseries: Add partial support for PCI
Alex
^ permalink raw reply
* [Qemu-devel] [PATCH 24/22] pseries: Add partial support for PCI
From: Alexander Graf @ 2011-10-31 4:12 UTC (permalink / raw)
To: qemu-devel; +Cc: Blue Swirl, Alexey Kardashevskiy, qemu-ppc, David Gibson
In-Reply-To: <1320006193-15219-1-git-send-email-agraf@suse.de>
From: David Gibson <david@gibson.dropbear.id.au>
This patch adds a PCI bus to the pseries machine. This instantiates
the qemu generic PCI bus code, advertises a PCI host bridge in the
guest's device tree and implements the RTAS methods specified by PAPR
to access PCI config space. It also sets up the memory regions we
need to provide windows into the PCI memory and IO space, and
advertises those to the guest.
However, because qemu can't yet emulate an IOMMU, which is mandatory on
pseries, PCI devices which use DMA (i.e. most of them) will not work with
this code alone. Still, this is enough to support the virtio_pci device
(which probably _should_ use emulated PCI DMA, but is specced to use
direct hypervisor access to guest physical memory instead).
[agraf] remove typedef which could cause compile errors
Signed-off-by: Alexey Kardashevskiy <aik@au1.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
Makefile.target | 1 +
hw/spapr.c | 36 ++++-
hw/spapr.h | 2 +
hw/spapr_pci.c | 508 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
hw/spapr_pci.h | 61 +++++++
5 files changed, 604 insertions(+), 4 deletions(-)
create mode 100644 hw/spapr_pci.c
create mode 100644 hw/spapr_pci.h
diff --git a/Makefile.target b/Makefile.target
index fe5f6f7..2329df5 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -248,6 +248,7 @@ obj-ppc-y += ppc_newworld.o
# IBM pSeries (sPAPR)
obj-ppc-$(CONFIG_PSERIES) += spapr.o spapr_hcall.o spapr_rtas.o spapr_vio.o
obj-ppc-$(CONFIG_PSERIES) += xics.o spapr_vty.o spapr_llan.o spapr_vscsi.o
+obj-ppc-$(CONFIG_PSERIES) += spapr_pci.o device-hotplug.o pci-hotplug.o
# PowerPC 4xx boards
obj-ppc-y += ppc4xx_devs.o ppc4xx_pci.o ppc405_uc.o ppc405_boards.o
obj-ppc-y += ppc440.o ppc440_bamboo.o
diff --git a/hw/spapr.c b/hw/spapr.c
index 933af32..bdaa938 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -39,10 +39,12 @@
#include "hw/spapr.h"
#include "hw/spapr_vio.h"
+#include "hw/spapr_pci.h"
#include "hw/xics.h"
#include "kvm.h"
#include "kvm_ppc.h"
+#include "pci.h"
#include "exec-memory.h"
@@ -62,6 +64,11 @@
#define MAX_CPUS 256
#define XICS_IRQS 1024
+#define SPAPR_PCI_BUID 0x800000020000001ULL
+#define SPAPR_PCI_MEM_WIN_ADDR (0x10000000000ULL + 0xA0000000)
+#define SPAPR_PCI_MEM_WIN_SIZE 0x20000000
+#define SPAPR_PCI_IO_WIN_ADDR (0x10000000000ULL + 0x80000000)
+
#define PHANDLE_XICP 0x00001111
sPAPREnvironment *spapr;
@@ -146,6 +153,14 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
&end_prop, sizeof(end_prop))));
_FDT((fdt_property_string(fdt, "qemu,boot-device", boot_device)));
+ /*
+ * Because we don't always invoke any firmware, we can't rely on
+ * that to do BAR allocation. Long term, we should probably do
+ * that ourselves, but for now, this setting (plus advertising the
+ * current BARs as 0) causes sufficiently recent kernels to to the
+ * BAR assignment themselves */
+ _FDT((fdt_property_cell(fdt, "linux,pci-probe-only", 0)));
+
_FDT((fdt_end_node(fdt)));
/* memory node(s) */
@@ -308,6 +323,7 @@ static void spapr_finalize_fdt(sPAPREnvironment *spapr,
{
int ret;
void *fdt;
+ sPAPRPHBState *phb;
fdt = g_malloc(FDT_MAX_SIZE);
@@ -320,6 +336,15 @@ static void spapr_finalize_fdt(sPAPREnvironment *spapr,
exit(1);
}
+ QLIST_FOREACH(phb, &spapr->phbs, list) {
+ ret = spapr_populate_pci_devices(phb, PHANDLE_XICP, fdt);
+ }
+
+ if (ret < 0) {
+ fprintf(stderr, "couldn't setup PCI devices in fdt\n");
+ exit(1);
+ }
+
/* RTAS */
ret = spapr_rtas_device_tree_setup(fdt, rtas_addr, rtas_size);
if (ret < 0) {
@@ -478,6 +503,12 @@ static void ppc_spapr_init(ram_addr_t ram_size,
}
}
+ /* Set up PCI */
+ spapr_create_phb(spapr, "pci", SPAPR_PCI_BUID,
+ SPAPR_PCI_MEM_WIN_ADDR,
+ SPAPR_PCI_MEM_WIN_SIZE,
+ SPAPR_PCI_IO_WIN_ADDR);
+
for (i = 0; i < nb_nics; i++) {
NICInfo *nd = &nd_table[i];
@@ -488,10 +519,7 @@ static void ppc_spapr_init(ram_addr_t ram_size,
if (strcmp(nd->model, "ibmveth") == 0) {
spapr_vlan_create(spapr->vio_bus, 0x1000 + i, nd);
} else {
- fprintf(stderr, "pSeries (sPAPR) platform does not support "
- "NIC model '%s' (only ibmveth is supported)\n",
- nd->model);
- exit(1);
+ pci_nic_init_nofail(&nd_table[i], nd->model, NULL);
}
}
diff --git a/hw/spapr.h b/hw/spapr.h
index 6657c33..df88f6a 100644
--- a/hw/spapr.h
+++ b/hw/spapr.h
@@ -4,10 +4,12 @@
#include "hw/xics.h"
struct VIOsPAPRBus;
+struct sPAPRPHBState;
struct icp_state;
typedef struct sPAPREnvironment {
struct VIOsPAPRBus *vio_bus;
+ QLIST_HEAD(, sPAPRPHBState) phbs;
struct icp_state *icp;
target_phys_addr_t ram_limit;
diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
new file mode 100644
index 0000000..2a5e637
--- /dev/null
+++ b/hw/spapr_pci.c
@@ -0,0 +1,508 @@
+/*
+ * QEMU sPAPR PCI host originated from Uninorth PCI host
+ *
+ * Copyright (c) 2011 Alexey Kardashevskiy, IBM Corporation.
+ * Copyright (C) 2011 David Gibson, IBM Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include "hw.h"
+#include "pci.h"
+#include "pci_host.h"
+#include "hw/spapr.h"
+#include "hw/spapr_pci.h"
+#include "exec-memory.h"
+#include <libfdt.h>
+
+#include "hw/pci_internals.h"
+
+static const uint32_t bars[] = {
+ PCI_BASE_ADDRESS_0, PCI_BASE_ADDRESS_1,
+ PCI_BASE_ADDRESS_2, PCI_BASE_ADDRESS_3,
+ PCI_BASE_ADDRESS_4, PCI_BASE_ADDRESS_5
+ /*, PCI_ROM_ADDRESS*/
+};
+
+static PCIDevice *find_dev(sPAPREnvironment *spapr,
+ uint64_t buid, uint32_t config_addr)
+{
+ DeviceState *qdev;
+ int devfn = (config_addr >> 8) & 0xFF;
+ sPAPRPHBState *phb;
+
+ QLIST_FOREACH(phb, &spapr->phbs, list) {
+ if (phb->buid != buid) {
+ continue;
+ }
+
+ QLIST_FOREACH(qdev, &phb->host_state.bus->qbus.children, sibling) {
+ PCIDevice *dev = (PCIDevice *)qdev;
+ if (dev->devfn == devfn) {
+ return dev;
+ }
+ }
+ }
+
+ return NULL;
+}
+
+static void rtas_ibm_read_pci_config(sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args,
+ uint32_t nret, target_ulong rets)
+{
+ uint32_t val, size, addr;
+ uint64_t buid = ((uint64_t)rtas_ld(args, 1) << 32) | rtas_ld(args, 2);
+ PCIDevice *dev = find_dev(spapr, buid, rtas_ld(args, 0));
+
+ if (!dev) {
+ rtas_st(rets, 0, -1);
+ return;
+ }
+ size = rtas_ld(args, 3);
+ addr = rtas_ld(args, 0) & 0xFF;
+ val = pci_default_read_config(dev, addr, size);
+ rtas_st(rets, 0, 0);
+ rtas_st(rets, 1, val);
+}
+
+static void rtas_read_pci_config(sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args,
+ uint32_t nret, target_ulong rets)
+{
+ uint32_t val, size, addr;
+ PCIDevice *dev = find_dev(spapr, 0, rtas_ld(args, 0));
+
+ if (!dev) {
+ rtas_st(rets, 0, -1);
+ return;
+ }
+ size = rtas_ld(args, 1);
+ addr = rtas_ld(args, 0) & 0xFF;
+ val = pci_default_read_config(dev, addr, size);
+ rtas_st(rets, 0, 0);
+ rtas_st(rets, 1, val);
+}
+
+static void rtas_ibm_write_pci_config(sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args,
+ uint32_t nret, target_ulong rets)
+{
+ uint32_t val, size, addr;
+ uint64_t buid = ((uint64_t)rtas_ld(args, 1) << 32) | rtas_ld(args, 2);
+ PCIDevice *dev = find_dev(spapr, buid, rtas_ld(args, 0));
+
+ if (!dev) {
+ rtas_st(rets, 0, -1);
+ return;
+ }
+ val = rtas_ld(args, 4);
+ size = rtas_ld(args, 3);
+ addr = rtas_ld(args, 0) & 0xFF;
+ pci_default_write_config(dev, addr, val, size);
+ rtas_st(rets, 0, 0);
+}
+
+static void rtas_write_pci_config(sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args,
+ uint32_t nret, target_ulong rets)
+{
+ uint32_t val, size, addr;
+ PCIDevice *dev = find_dev(spapr, 0, rtas_ld(args, 0));
+
+ if (!dev) {
+ rtas_st(rets, 0, -1);
+ return;
+ }
+ val = rtas_ld(args, 2);
+ size = rtas_ld(args, 1);
+ addr = rtas_ld(args, 0) & 0xFF;
+ pci_default_write_config(dev, addr, val, size);
+ rtas_st(rets, 0, 0);
+}
+
+static int pci_spapr_map_irq(PCIDevice *pci_dev, int irq_num)
+{
+ /*
+ * Here we need to convert pci_dev + irq_num to some unique value
+ * which is less than number of IRQs on the specific bus (now it
+ * is 16). At the moment irq_num == device_id (number of the
+ * slot?)
+ * FIXME: we should swizzle in fn and irq_num
+ */
+ return (pci_dev->devfn >> 3) % SPAPR_PCI_NUM_LSI;
+}
+
+static void pci_spapr_set_irq(void *opaque, int irq_num, int level)
+{
+ /*
+ * Here we use the number returned by pci_spapr_map_irq to find a
+ * corresponding qemu_irq.
+ */
+ sPAPRPHBState *phb = opaque;
+
+ qemu_set_irq(phb->lsi_table[irq_num].qirq, level);
+}
+
+static int spapr_phb_init(SysBusDevice *s)
+{
+ sPAPRPHBState *phb = FROM_SYSBUS(sPAPRPHBState, s);
+ int i;
+
+ /* Initialize the LSI table */
+ for (i = 0; i < SPAPR_PCI_NUM_LSI; i++) {
+ qemu_irq qirq;
+ uint32_t num;
+
+ qirq = spapr_allocate_irq(0, &num);
+ if (!qirq) {
+ return -1;
+ }
+
+ phb->lsi_table[i].dt_irq = num;
+ phb->lsi_table[i].qirq = qirq;
+ }
+
+ return 0;
+}
+
+static int spapr_main_pci_host_init(PCIDevice *d)
+{
+ return 0;
+}
+
+static PCIDeviceInfo spapr_main_pci_host_info = {
+ .qdev.name = "spapr-pci-host-bridge",
+ .qdev.size = sizeof(PCIDevice),
+ .init = spapr_main_pci_host_init,
+};
+
+static void spapr_register_devices(void)
+{
+ sysbus_register_dev("spapr-pci-host-bridge", sizeof(sPAPRPHBState),
+ spapr_phb_init);
+ pci_qdev_register(&spapr_main_pci_host_info);
+}
+
+device_init(spapr_register_devices)
+
+static uint64_t spapr_io_read(void *opaque, target_phys_addr_t addr,
+ unsigned size)
+{
+ switch (size) {
+ case 1:
+ return cpu_inb(addr);
+ case 2:
+ return cpu_inw(addr);
+ case 4:
+ return cpu_inl(addr);
+ }
+ assert(0);
+}
+
+static void spapr_io_write(void *opaque, target_phys_addr_t addr,
+ uint64_t data, unsigned size)
+{
+ switch (size) {
+ case 1:
+ cpu_outb(addr, data);
+ return;
+ case 2:
+ cpu_outw(addr, data);
+ return;
+ case 4:
+ cpu_outl(addr, data);
+ return;
+ }
+ assert(0);
+}
+
+static MemoryRegionOps spapr_io_ops = {
+ .endianness = DEVICE_LITTLE_ENDIAN,
+ .read = spapr_io_read,
+ .write = spapr_io_write
+};
+
+void spapr_create_phb(sPAPREnvironment *spapr,
+ const char *busname, uint64_t buid,
+ uint64_t mem_win_addr, uint64_t mem_win_size,
+ uint64_t io_win_addr)
+{
+ DeviceState *dev;
+ SysBusDevice *s;
+ sPAPRPHBState *phb;
+ PCIBus *bus;
+ char namebuf[strlen(busname)+11];
+
+ dev = qdev_create(NULL, "spapr-pci-host-bridge");
+ qdev_init_nofail(dev);
+ s = sysbus_from_qdev(dev);
+ phb = FROM_SYSBUS(sPAPRPHBState, s);
+
+ phb->mem_win_addr = mem_win_addr;
+
+ sprintf(namebuf, "%s-mem", busname);
+ memory_region_init(&phb->memspace, namebuf, INT64_MAX);
+
+ sprintf(namebuf, "%s-memwindow", busname);
+ memory_region_init_alias(&phb->memwindow, namebuf, &phb->memspace,
+ SPAPR_PCI_MEM_WIN_BUS_OFFSET, mem_win_size);
+ memory_region_add_subregion(get_system_memory(), mem_win_addr,
+ &phb->memwindow);
+
+ phb->io_win_addr = io_win_addr;
+
+ /* On ppc, we only have MMIO no specific IO space from the CPU
+ * perspective. In theory we ought to be able to embed the PCI IO
+ * memory region direction in the system memory space. However,
+ * if any of the IO BAR subregions use the old_portio mechanism,
+ * that won't be processed properly unless accessed from the
+ * system io address space. This hack to bounce things via
+ * system_io works around the problem until all the users of
+ * old_portion are updated */
+ sprintf(namebuf, "%s-io", busname);
+ memory_region_init(&phb->iospace, namebuf, SPAPR_PCI_IO_WIN_SIZE);
+ /* FIXME: fix to support multiple PHBs */
+ memory_region_add_subregion(get_system_io(), 0, &phb->iospace);
+
+ sprintf(namebuf, "%s-iowindow", busname);
+ memory_region_init_io(&phb->iowindow, &spapr_io_ops, phb,
+ namebuf, SPAPR_PCI_IO_WIN_SIZE);
+ memory_region_add_subregion(get_system_memory(), io_win_addr,
+ &phb->iowindow);
+
+ phb->host_state.bus = bus = pci_register_bus(&phb->busdev.qdev, busname,
+ pci_spapr_set_irq,
+ pci_spapr_map_irq,
+ phb,
+ &phb->memspace, &phb->iospace,
+ PCI_DEVFN(0, 0),
+ SPAPR_PCI_NUM_LSI);
+
+ spapr_rtas_register("read-pci-config", rtas_read_pci_config);
+ spapr_rtas_register("write-pci-config", rtas_write_pci_config);
+ spapr_rtas_register("ibm,read-pci-config", rtas_ibm_read_pci_config);
+ spapr_rtas_register("ibm,write-pci-config", rtas_ibm_write_pci_config);
+
+ QLIST_INSERT_HEAD(&spapr->phbs, phb, list);
+
+ /* pci_bus_set_mem_base(bus, mem_va_start - SPAPR_PCI_MEM_BAR_START); */
+}
+
+/* Macros to operate with address in OF binding to PCI */
+#define b_x(x, p, l) (((x) & ((1<<(l))-1)) << (p))
+#define b_n(x) b_x((x), 31, 1) /* 0 if relocatable */
+#define b_p(x) b_x((x), 30, 1) /* 1 if prefetchable */
+#define b_t(x) b_x((x), 29, 1) /* 1 if the address is aliased */
+#define b_ss(x) b_x((x), 24, 2) /* the space code */
+#define b_bbbbbbbb(x) b_x((x), 16, 8) /* bus number */
+#define b_ddddd(x) b_x((x), 11, 5) /* device number */
+#define b_fff(x) b_x((x), 8, 3) /* function number */
+#define b_rrrrrrrr(x) b_x((x), 0, 8) /* register number */
+
+static uint32_t regtype_to_ss(uint8_t type)
+{
+ if (type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
+ return 3;
+ }
+ if (type == PCI_BASE_ADDRESS_SPACE_IO) {
+ return 1;
+ }
+ return 2;
+}
+
+int spapr_populate_pci_devices(sPAPRPHBState *phb,
+ uint32_t xics_phandle,
+ void *fdt)
+{
+ PCIBus *bus = phb->host_state.bus;
+ int bus_off, node_off = 0, devid, fn, i, n, devices;
+ DeviceState *qdev;
+ char nodename[256];
+ struct {
+ uint32_t hi;
+ uint64_t addr;
+ uint64_t size;
+ } __attribute__((packed)) reg[PCI_NUM_REGIONS + 1],
+ assigned_addresses[PCI_NUM_REGIONS];
+ uint32_t bus_range[] = { cpu_to_be32(0), cpu_to_be32(0xff) };
+ struct {
+ uint32_t hi;
+ uint64_t child;
+ uint64_t parent;
+ uint64_t size;
+ } __attribute__((packed)) ranges[] = {
+ {
+ cpu_to_be32(b_ss(1)), cpu_to_be64(0),
+ cpu_to_be64(phb->io_win_addr),
+ cpu_to_be64(memory_region_size(&phb->iospace)),
+ },
+ {
+ cpu_to_be32(b_ss(2)), cpu_to_be64(SPAPR_PCI_MEM_WIN_BUS_OFFSET),
+ cpu_to_be64(phb->mem_win_addr),
+ cpu_to_be64(memory_region_size(&phb->memwindow)),
+ },
+ };
+ uint64_t bus_reg[] = { cpu_to_be64(phb->buid), 0 };
+ uint32_t interrupt_map_mask[] = {
+ cpu_to_be32(b_ddddd(-1)|b_fff(-1)), 0x0, 0x0, 0x0};
+ uint32_t interrupt_map[bus->nirq][7];
+
+ /* Start populating the FDT */
+ sprintf(nodename, "pci@%" PRIx64, phb->buid);
+ bus_off = fdt_add_subnode(fdt, 0, nodename);
+ if (bus_off < 0) {
+ return bus_off;
+ }
+
+#define _FDT(exp) \
+ do { \
+ int ret = (exp); \
+ if (ret < 0) { \
+ return ret; \
+ } \
+ } while (0)
+
+ /* Write PHB properties */
+ _FDT(fdt_setprop_string(fdt, bus_off, "device_type", "pci"));
+ _FDT(fdt_setprop_string(fdt, bus_off, "compatible", "IBM,Logical_PHB"));
+ _FDT(fdt_setprop_cell(fdt, bus_off, "#address-cells", 0x3));
+ _FDT(fdt_setprop_cell(fdt, bus_off, "#size-cells", 0x2));
+ _FDT(fdt_setprop_cell(fdt, bus_off, "#interrupt-cells", 0x1));
+ _FDT(fdt_setprop(fdt, bus_off, "used-by-rtas", NULL, 0));
+ _FDT(fdt_setprop(fdt, bus_off, "bus-range", &bus_range, sizeof(bus_range)));
+ _FDT(fdt_setprop(fdt, bus_off, "ranges", &ranges, sizeof(ranges)));
+ _FDT(fdt_setprop(fdt, bus_off, "reg", &bus_reg, sizeof(bus_reg)));
+ _FDT(fdt_setprop(fdt, bus_off, "interrupt-map-mask",
+ &interrupt_map_mask, sizeof(interrupt_map_mask)));
+
+ /* Populate PCI devices and allocate IRQs */
+ devices = 0;
+ QLIST_FOREACH(qdev, &bus->qbus.children, sibling) {
+ PCIDevice *dev = DO_UPCAST(PCIDevice, qdev, qdev);
+ int irq_index = pci_spapr_map_irq(dev, 0);
+ uint32_t *irqmap = interrupt_map[devices];
+ uint8_t *config = dev->config;
+
+ devid = dev->devfn >> 3;
+ fn = dev->devfn & 7;
+
+ sprintf(nodename, "pci@%u,%u", devid, fn);
+
+ /* Allocate interrupt from the map */
+ if (devid > bus->nirq) {
+ printf("Unexpected behaviour in spapr_populate_pci_devices,"
+ "wrong devid %u\n", devid);
+ exit(-1);
+ }
+ irqmap[0] = cpu_to_be32(b_ddddd(devid)|b_fff(fn));
+ irqmap[1] = 0;
+ irqmap[2] = 0;
+ irqmap[3] = 0;
+ irqmap[4] = cpu_to_be32(xics_phandle);
+ irqmap[5] = cpu_to_be32(phb->lsi_table[irq_index].dt_irq);
+ irqmap[6] = cpu_to_be32(0x8);
+
+ /* Add node to FDT */
+ node_off = fdt_add_subnode(fdt, bus_off, nodename);
+ if (node_off < 0) {
+ return node_off;
+ }
+
+ _FDT(fdt_setprop_cell(fdt, node_off, "vendor-id",
+ pci_get_word(&config[PCI_VENDOR_ID])));
+ _FDT(fdt_setprop_cell(fdt, node_off, "device-id",
+ pci_get_word(&config[PCI_DEVICE_ID])));
+ _FDT(fdt_setprop_cell(fdt, node_off, "revision-id",
+ pci_get_byte(&config[PCI_REVISION_ID])));
+ _FDT(fdt_setprop_cell(fdt, node_off, "class-code",
+ pci_get_long(&config[PCI_CLASS_REVISION]) >> 8));
+ _FDT(fdt_setprop_cell(fdt, node_off, "subsystem-id",
+ pci_get_word(&config[PCI_SUBSYSTEM_ID])));
+ _FDT(fdt_setprop_cell(fdt, node_off, "subsystem-vendor-id",
+ pci_get_word(&config[PCI_SUBSYSTEM_VENDOR_ID])));
+
+ /* Config space region comes first */
+ reg[0].hi = cpu_to_be32(
+ b_n(0) |
+ b_p(0) |
+ b_t(0) |
+ b_ss(0/*config*/) |
+ b_bbbbbbbb(0) |
+ b_ddddd(devid) |
+ b_fff(fn));
+ reg[0].addr = 0;
+ reg[0].size = 0;
+
+ n = 0;
+ for (i = 0; i < PCI_NUM_REGIONS; ++i) {
+ if (0 == dev->io_regions[i].size) {
+ continue;
+ }
+
+ reg[n+1].hi = cpu_to_be32(
+ b_n(0) |
+ b_p(0) |
+ b_t(0) |
+ b_ss(regtype_to_ss(dev->io_regions[i].type)) |
+ b_bbbbbbbb(0) |
+ b_ddddd(devid) |
+ b_fff(fn) |
+ b_rrrrrrrr(bars[i]));
+ reg[n+1].addr = 0;
+ reg[n+1].size = cpu_to_be64(dev->io_regions[i].size);
+
+ assigned_addresses[n].hi = cpu_to_be32(
+ b_n(1) |
+ b_p(0) |
+ b_t(0) |
+ b_ss(regtype_to_ss(dev->io_regions[i].type)) |
+ b_bbbbbbbb(0) |
+ b_ddddd(devid) |
+ b_fff(fn) |
+ b_rrrrrrrr(bars[i]));
+
+ /*
+ * Writing zeroes to assigned_addresses causes the guest kernel to
+ * reassign BARs
+ */
+ assigned_addresses[n].addr = cpu_to_be64(dev->io_regions[i].addr);
+ assigned_addresses[n].size = reg[n+1].size;
+
+ ++n;
+ }
+ _FDT(fdt_setprop(fdt, node_off, "reg", reg, sizeof(reg[0])*(n+1)));
+ _FDT(fdt_setprop(fdt, node_off, "assigned-addresses",
+ assigned_addresses,
+ sizeof(assigned_addresses[0])*(n)));
+ _FDT(fdt_setprop_cell(fdt, node_off, "interrupts",
+ pci_get_byte(&config[PCI_INTERRUPT_PIN])));
+
+ ++devices;
+ }
+
+ /* Write interrupt map */
+ _FDT(fdt_setprop(fdt, bus_off, "interrupt-map", &interrupt_map,
+ devices * sizeof(interrupt_map[0])));
+
+ return 0;
+}
diff --git a/hw/spapr_pci.h b/hw/spapr_pci.h
new file mode 100644
index 0000000..213340c
--- /dev/null
+++ b/hw/spapr_pci.h
@@ -0,0 +1,61 @@
+/*
+ * QEMU SPAPR PCI BUS definitions
+ *
+ * Copyright (c) 2011 Alexey Kardashevskiy <aik@au1.ibm.com>
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see <http://www.gnu.org/licenses/>.
+ */
+#if !defined(__HW_SPAPR_H__)
+#error Please include spapr.h before this file!
+#endif
+
+#if !defined(__HW_SPAPR_PCI_H__)
+#define __HW_SPAPR_PCI_H__
+
+#include "hw/pci_host.h"
+#include "hw/xics.h"
+
+#define SPAPR_PCI_NUM_LSI 16
+
+typedef struct sPAPRPHBState {
+ SysBusDevice busdev;
+ PCIHostState host_state;
+
+ uint64_t buid;
+
+ MemoryRegion memspace, iospace;
+ target_phys_addr_t mem_win_addr, io_win_addr;
+ MemoryRegion memwindow, iowindow;
+
+ struct {
+ uint32_t dt_irq;
+ qemu_irq qirq;
+ } lsi_table[SPAPR_PCI_NUM_LSI];
+
+ QLIST_ENTRY(sPAPRPHBState) list;
+} sPAPRPHBState;
+
+#define SPAPR_PCI_MEM_WIN_BUS_OFFSET 0x80000000ULL
+#define SPAPR_PCI_IO_WIN_SIZE 0x10000
+
+void spapr_create_phb(sPAPREnvironment *spapr,
+ const char *busname, uint64_t buid,
+ uint64_t mem_win_addr, uint64_t mem_win_size,
+ uint64_t io_win_addr);
+
+int spapr_populate_pci_devices(sPAPRPHBState *phb,
+ uint32_t xics_phandle,
+ void *fdt);
+
+#endif /* __HW_SPAPR_PCI_H__ */
--
1.6.0.2
^ permalink raw reply related
* [Qemu-devel] [PATCH 23/22] ppc: Alter CPU state to mask out TCG unimplemented instructions as appropriate
From: Alexander Graf @ 2011-10-31 4:12 UTC (permalink / raw)
To: qemu-devel; +Cc: Blue Swirl, qemu-ppc, David Gibson
In-Reply-To: <1320006193-15219-1-git-send-email-agraf@suse.de>
From: David Gibson <david@gibson.dropbear.id.au>
The CPU state contains two bitmaps, initialized from the CPU spec
which describes which instructions are implemented on the CPU. A
couple of bits are defined which cover instructions (VSX and DFP)
which are not currently implemented in TCG. So far, these are only
used to handle the case of -cpu host because a KVM guest can use
the instructions when the host CPU supports them.
However, it's a mild layering violation to simply not include those
bits in the CPU descriptions for those CPUs that do support them,
just because we can't handle them in TCG. This patch corrects the
situation, so that the instruction bits _are_ shown correctly in the
cpu spec table, but are masked out from the cpu state in the non-KVM
case.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
target-ppc/cpu.h | 26 ++++++++++++++++++++++++++
target-ppc/translate_init.c | 20 +++++++++++++++++---
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 3ef4eba..e84108c 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1856,6 +1856,30 @@ enum {
/* popcntw and popcntd instructions */
PPC_POPCNTWD = 0x8000000000000000ULL,
+#define PPC_TCG_INSNS (PPC_INSNS_BASE | PPC_POWER | PPC_POWER2 \
+ | PPC_POWER_RTC | PPC_POWER_BR | PPC_64B \
+ | PPC_64BX | PPC_64H | PPC_WAIT | PPC_MFTB \
+ | PPC_602_SPEC | PPC_ISEL | PPC_POPCNTB \
+ | PPC_STRING | PPC_FLOAT | PPC_FLOAT_EXT \
+ | PPC_FLOAT_FSQRT | PPC_FLOAT_FRES \
+ | PPC_FLOAT_FRSQRTE | PPC_FLOAT_FRSQRTES \
+ | PPC_FLOAT_FSEL | PPC_FLOAT_STFIWX \
+ | PPC_ALTIVEC | PPC_SPE | PPC_SPE_SINGLE \
+ | PPC_SPE_DOUBLE | PPC_MEM_TLBIA \
+ | PPC_MEM_TLBIE | PPC_MEM_TLBSYNC \
+ | PPC_MEM_SYNC | PPC_MEM_EIEIO \
+ | PPC_CACHE | PPC_CACHE_ICBI \
+ | PPC_CACHE_DCBZ | PPC_CACHE_DCBZT \
+ | PPC_CACHE_DCBA | PPC_CACHE_LOCK \
+ | PPC_EXTERN | PPC_SEGMENT | PPC_6xx_TLB \
+ | PPC_74xx_TLB | PPC_40x_TLB | PPC_SEGMENT_64B \
+ | PPC_SLBI | PPC_WRTEE | PPC_40x_EXCP \
+ | PPC_405_MAC | PPC_440_SPEC | PPC_BOOKE \
+ | PPC_MFAPIDI | PPC_TLBIVA | PPC_TLBIVAX \
+ | PPC_4xx_COMMON | PPC_40x_ICBT | PPC_RFMCI \
+ | PPC_RFDI | PPC_DCR | PPC_DCRX | PPC_DCRUX \
+ | PPC_POPCNTWD)
+
/* extended type values */
/* BookE 2.06 PowerPC specification */
@@ -1864,6 +1888,8 @@ enum {
PPC2_VSX = 0x0000000000000002ULL,
/* Decimal Floating Point (DFP) */
PPC2_DFP = 0x0000000000000004ULL,
+
+#define PPC_TCG_INSNS2 (PPC2_BOOKE206)
};
/*****************************************************************************/
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 4dfd7f3..8a7233f 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -6519,9 +6519,7 @@ static void init_proc_970MP (CPUPPCState *env)
PPC_64B | PPC_ALTIVEC | \
PPC_SEGMENT_64B | PPC_SLBI | \
PPC_POPCNTB | PPC_POPCNTWD)
-/* FIXME: Should also have PPC2_VSX and PPC2_DFP, but we don't
- * implement those in TCG yet */
-#define POWERPC_INSNS2_POWER7 (PPC_NONE)
+#define POWERPC_INSNS2_POWER7 (PPC2_VSX | PPC2_DFP)
#define POWERPC_MSRM_POWER7 (0x800000000204FF36ULL)
#define POWERPC_MMU_POWER7 (POWERPC_MMU_2_06)
#define POWERPC_EXCP_POWER7 (POWERPC_EXCP_POWER7)
@@ -9848,6 +9846,22 @@ int cpu_ppc_register_internal (CPUPPCState *env, const ppc_def_t *def)
env->bus_model = def->bus_model;
env->insns_flags = def->insns_flags;
env->insns_flags2 = def->insns_flags2;
+ if (!kvm_enabled()) {
+ /* TCG doesn't (yet) emulate some groups of instructions that
+ * are implemented on some otherwise supported CPUs (e.g. VSX
+ * and decimal floating point instructions on POWER7). We
+ * remove unsupported instruction groups from the cpu state's
+ * instruction masks and hope the guest can cope. For at
+ * least the pseries machine, the unavailability of these
+ * instructions can be advertise to the guest via the device
+ * tree.
+ *
+ * FIXME: we should have a similar masking for CPU features
+ * not accessible under KVM, but so far, there aren't any of
+ * those. */
+ env->insns_flags &= PPC_TCG_INSNS;
+ env->insns_flags2 &= PPC_TCG_INSNS2;
+ }
env->flags = def->flags;
env->bfd_mach = def->bfd_mach;
env->check_pow = def->check_pow;
--
1.6.0.2
^ permalink raw reply related
* Re: New Feature wanted: Is it possible to let git clone continue last break point?
From: Tay Ray Chuan @ 2011-10-31 4:00 UTC (permalink / raw)
To: netroby; +Cc: Git Mail List
In-Reply-To: <CAEZo+gcj5q2UYnak1+1UG7pPzoeaUr=QLsiCiNXbC_n+JQbKQQ@mail.gmail.com>
This is a hard problem that hasn't been solved. Year after year, it's
a GSoC proposal...
What you can do is use --depth 1 with your git-clone; then "extend"
the depth incrementally.
-- Cheers,Ray Chuan
On Mon, Oct 31, 2011 at 10:28 AM, netroby <hufeng1987@gmail.com> wrote:
> Is it possible to let git clone continue last break point.
> when we git clone very large project from the web, we may face some
> interupt, then we must clone it from zero .
>
> it is bad feeling for low connection speed users.
>
> please help us out.
>
> we need git clone continue last break point
>
> netroby
> ----------------------------------
> http://www.netroby.com
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/3] pseries: Add partial support for PCI
From: Alexander Graf @ 2011-10-31 3:55 UTC (permalink / raw)
To: David Gibson; +Cc: qemu-ppc, qemu-devel
In-Reply-To: <1320031007-25884-3-git-send-email-david@gibson.dropbear.id.au>
On 31.10.2011, at 04:16, David Gibson wrote:
> This patch adds a PCI bus to the pseries machine. This instantiates
> the qemu generic PCI bus code, advertises a PCI host bridge in the
> guest's device tree and implements the RTAS methods specified by PAPR
> to access PCI config space. It also sets up the memory regions we
> need to provide windows into the PCI memory and IO space, and
> advertises those to the guest.
>
> However, because qemu can't yet emulate an IOMMU, which is mandatory on
> pseries, PCI devices which use DMA (i.e. most of them) will not work with
> this code alone. Still, this is enough to support the virtio_pci device
> (which probably _should_ use emulated PCI DMA, but is specced to use
> direct hypervisor access to guest physical memory instead).
>
> Signed-off-by: Alexey Kardashevskiy <aik@au1.ibm.com>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied with the following patch folded in:
diff --git a/hw/spapr_pci.h b/hw/spapr_pci.h
index 4bb8dfb..213340c 100644
--- a/hw/spapr_pci.h
+++ b/hw/spapr_pci.h
@@ -16,14 +16,16 @@
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, see <http://www.gnu.org/licenses/>.
*/
+#if !defined(__HW_SPAPR_H__)
+#error Please include spapr.h before this file!
+#endif
+
#if !defined(__HW_SPAPR_PCI_H__)
#define __HW_SPAPR_PCI_H__
#include "hw/pci_host.h"
#include "hw/xics.h"
-typedef struct sPAPREnvironment sPAPREnvironment;
-
#define SPAPR_PCI_NUM_LSI 16
typedef struct sPAPRPHBState {
Alex
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 1/3] ppc: Alter CPU state to mask out TCG unimplemented instructions as appropriate
From: Alexander Graf @ 2011-10-31 3:51 UTC (permalink / raw)
To: David Gibson; +Cc: qemu-ppc, qemu-devel
In-Reply-To: <1320031007-25884-2-git-send-email-david@gibson.dropbear.id.au>
On 31.10.2011, at 04:16, David Gibson wrote:
> The CPU state contains two bitmaps, initialized from the CPU spec
> which describes which instructions are implemented on the CPU. A
> couple of bits are defined which cover instructions (VSX and DFP)
> which are not currently implemented in TCG. So far, these are only
> used to handle the case of -cpu host because a KVM guest can use
> the instructions when the host CPU supports them.
>
> However, it's a mild layering violation to simply not include those
> bits in the CPU descriptions for those CPUs that do support them,
> just because we can't handle them in TCG. This patch corrects the
> situation, so that the instruction bits _are_ shown correctly in the
> cpu spec table, but are masked out from the cpu state in the non-KVM
> case.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Thanks, applied.
Alex
^ permalink raw reply
* Re: [PATCH] m68k: Revive lost DIO bus config option
From: Greg Ungerer @ 2011-10-31 3:51 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Greg Ungerer, linux-m68k, linux-kernel
In-Reply-To: <1319835295-19519-1-git-send-email-geert@linux-m68k.org>
Hi Geert,
On 29/10/11 06:54, Geert Uytterhoeven wrote:
> commit 0e152d80507b75c00aac60f2ffc586360687cd52 ("m68k: reorganize Kconfig
> options to improve mmu/non-mmu selections") accidentally dropped the DIO
> bus config option. Re-add it to the "Bus support" section.
>
> Signed-off-by: Geert Uytterhoeven<geert@linux-m68k.org>
Oops, another one.
Acked-by: Greg Ungerer <gerg@uclinux.org>
Are you going to push these to Linus, or do you want me to
collect these fixes and push?
Regards
Greg
> arch/m68k/Kconfig.bus | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/m68k/Kconfig.bus b/arch/m68k/Kconfig.bus
> index 7703b54..983e176 100644
> --- a/arch/m68k/Kconfig.bus
> +++ b/arch/m68k/Kconfig.bus
> @@ -2,6 +2,15 @@ if MMU
>
> comment "Bus Support"
>
> +config DIO
> + bool "DIO bus support"
> + depends on HP300
> + default y
> + help
> + Say Y here to enable support for the "DIO" expansion bus used in
> + HP300 machines. If you are using such a system you almost certainly
> + want this.
> +
> config NUBUS
> bool
> depends on MAC
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.