* Re: [patch 27/28] posix-timers: Add support for fd based clocks
From: john stultz @ 2011-02-01 21:38 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110201134420.062860200@linutronix.de>
On Tue, 2011-02-01 at 13:52 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (posix-timers-add-support-for-fd-based-clocks.patch)
> From: Richard Cochran <richard.cochran@omicron.at>
>
> Extend the negative clockids which are currently used by posix cpu
> timers to encode the PID with a file descriptor based type which
> encodes the fd in the upper bits.
>
> Originally-from: Richard Cochran <richard.cochran@omicron.at>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: John Stultz <john.stultz@linaro.org>
Acked-by: John Stultz <johnstul@us.ibm.com>
^ permalink raw reply
* IPv6 filtering
From: Jonathan Tripathy @ 2011-02-01 21:38 UTC (permalink / raw)
To: netfilter
Hi Everyone,
We host VPSes using Xen to customers. We run iptables and ebtables on
our Xen hosts to make sure that each VPS can only use the IP and MAC
addresses assigned to them.
With IPv6, does anyone have any experience on how to do this? I know we
can use ip6tables, but isn't there some trickery with NDP (Which
replaces ARP)?
Thanks
^ permalink raw reply
* Re: RAID HDDs spin up sequence
From: Stan Hoeppner @ 2011-02-01 21:37 UTC (permalink / raw)
To: John Robinson; +Cc: Phillip Susi, Piergiorgio Sartor, linux-raid
In-Reply-To: <4D48062E.9040405@anonymous.org.uk>
John Robinson put forth on 2/1/2011 7:10 AM:
> That'd be an excessive amount of time to wait. A quarter of a second is more
> than enough, a tenth of a second would probably be enough. It's just the motor
> inrush current you're trying to avoid having simultaneously.
The blowers in a typical 2U server chassis will have slightly more startup
current draw than the drives, assuming 5 80mm blowers and 8 2.5" drives. Mobos
don't do staggered startup of blowers. Thus, staggering the drive spin up is
pointless. Add to that the fact that most server chassis ship with PSUs large
enough to carry the current draw of anything/everything you can stuff into them.
> So waiting another second for your array to wake up would mean you could use a
> sensibly-sized PSU operating in its 80%+ efficiency range, rather than a huge
> PSU operating inefficiently.
A typical 2.5" 10K RPM 600GB enterprise HDD, such as the Seagate Savvio, has a
startup draw of 24.1 watts combined from the 12v and 5v rails. A RAID/JBOD
chassis of 24 such drives, which is sold by dozens of vendors today, will draw
only 578.4 watts with all drives spinning up concurrently. Most such chassis on
the market today are sold with 800w to 1800w redundant PSUs, again, making
staggered spin up moot.
--
Stan
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Nicolas Pitre @ 2011-02-01 21:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jonathan Nieder, Dmitry S. Kravtsov, git
In-Reply-To: <201102011451.17456.jnareb@gmail.com>
On Tue, 1 Feb 2011, Jakub Narebski wrote:
> On Sun, 30 Jan 2011, Jonathan Nieder wrote:
> > Dmitry S. Kravtsov wrote:
> >
> > > resumable clone/fetch (and other remote operations)
> >
> > Jakub Narebski seems to be interested in this and Nicolas Pitre has
> > given some good advice about it. You can get something usable today
> > by putting up a git bundle for download over HTTP or rsync, so it is
> > possible that this just involves some UI (porcelain) and documentation
> > work to become standard practice.
>
> I wouldn't say that: it is Nicolas Pitre (IIRC) who was doing the work;
> I was only interested party posting comments, but no code.
No, I'm not working on that. I provided suggestions on how to go about
it in the past:
1) The git-archive based solution:
http://article.gmane.org/gmane.comp.version-control.git/126431
Relatively simple to implement, with questionable efficiency if you
care about the full history, but perfectly suited for shallow clones
which is what people with flaky connections should aim for anyway.
2) The bundle based solution:
http://article.gmane.org/gmane.comp.version-control.git/164699
(see towards the end of the message)
This was about BitTorrent distribution, but any resumable transport
can be applied to the bundle.
Extremely simple to implement, as this all can be scripted on top of
existing tools. Good for the bulk of history, but there is always a
risk for problems during the update of the repository from the
bundle's state up to the most recent commits which has to fall back
to the non resumable smart Git protocol.
There is also some possibility that the cache pack work might be
leveraged to provide a resumable clone solution similar to #2 above, but
that would of course share the same flaws.
> Again, this feature is not very easy to implement, and would require
> knowledge of git internals including "smart" git transport ("Pro Git"
> book can help there).
The two proposed solutions above require no prior knowledge of the smart
Git protocol, and they should be pretty simple to implement. Certainly
in the reach of a GSOC student.
> > > GitTorrent Protocol, or git-mirror
> >
> > Sam Vilain and Jonas Fonseca did some good work on this, but it's
> > stalled.
>
> There was some recent discussion on this on git mailing llist, but
> without any code.
>
> One would need to know similar areas as for "resumable clone" feature.
> Plus some knowledge on P2P transport in GitTorrent case.
Again, please see
http://article.gmane.org/gmane.comp.version-control.git/164699
This is simple, and with guaranteed results. Why no one was interested
in implementing that yet I don't know.
Nicolas
^ permalink raw reply
* Re: [patch] xfsprogs: repair never return if device removed
From: Christoph Hellwig @ 2011-02-01 21:39 UTC (permalink / raw)
To: Ajeet Yadav; +Cc: xfs
In-Reply-To: <AANLkTimF7ie1DSka0MYQRdF04kcaQZ3rHJerhSdsV_yt@mail.gmail.com>
Thanks, applied.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [Buildroot] [PATCH] Makefile.package.in: fix upper case $(PKG)_SITE_METHOD
From: Bjørn Forsman @ 2011-02-01 21:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <AANLkTi=-RcJORsWa+Zm29xcMhEX2STMJYOyXRTN7Qjpa@mail.gmail.com>
2011/2/1 Bj?rn Forsman <bjorn.forsman@gmail.com>:
> On 1 February 2011 21:34, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> On Tue, ?1 Feb 2011 12:18:49 +0100
>> Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:
>>
>>> ? ? ? ? ? ? ? case "$($(PKG)_SITE_METHOD)" in \
>>> - ? ? ? ? ? ? ? ? ? ? git) $($(DL_MODE)_GIT) && exit ;; \
>>> - ? ? ? ? ? ? ? ? ? ? svn) $($(DL_MODE)_SVN) && exit ;; \
>>> - ? ? ? ? ? ? ? ? ? ? bzr) $($(DL_MODE)_BZR) && exit ;; \
>>> + ? ? ? ? ? ? ? ? ? ? GIT) $($(DL_MODE)_GIT) && exit ;; \
>>> + ? ? ? ? ? ? ? ? ? ? SVN) $($(DL_MODE)_SVN) && exit ;; \
>>> + ? ? ? ? ? ? ? ? ? ? BZR) $($(DL_MODE)_BZR) && exit ;; \
>>> ? ? ? ? ? ? ? ? ? ? ? *) $(call $(DL_MODE)_WGET,$(1),$(2)) && exit ;; \
>>> ? ? ? ? ? ? ? esac ; \
>>> ? ? ? fi ; \
>>
>> No. This is going to break:
>>
>> ? ? ? ?# Try automatic detection using the scheme part of the URI
>> ? ? ? ?$(2)_SITE_METHOD = $(firstword $(subst ://, ,$(call qstrip,$($(2)_SITE))))
>>
>> is used to detect the site method from the URI, like :
>>
>> ? ? ? ?git://....
>>
>> or
>>
>> ? ? ? ?svn://....
>>
>> so if only upper case site methods are accepted, it's not going to work.
>
> Oh, didn't see that one.
>
>> And more generally, I'd prefer to keep the existing lower-case writing
>> of the site method, since it is coherent with how it's written in the
>> URI.
>
> How about my first patch then, allowing both upper and lower case (to
> stay in sync with doc)? Or reword the doc?
>
> Having doc != implementation is confusing so one of them should get patched :-)
Hm, I see other places where lower case names are used:
ifeq ($$($(2)_SITE_METHOD),svn)
DL_TOOLS_DEPENDENCIES += svn
else ifeq ($$($(2)_SITE_METHOD),git)
DL_TOOLS_DEPENDENCIES += git
else ifeq ($$($(2)_SITE_METHOD),bzr)
DL_TOOLS_DEPENDENCIES += bzr
endif # SITE_METHOD
So the best thing is probably to patch the documentation.
^ permalink raw reply
* Re: [patch 26/28] posix_clocks: Add clock_adjtime for x86
From: john stultz @ 2011-02-01 21:36 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110201134419.968905083@linutronix.de>
On Tue, 2011-02-01 at 13:52 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (posix_clocks-add-clock_adjtime-for-x86.patch)
> This patch adds the clock_adjtime system call to the x86 architecture.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> Cc: John Stultz <john.stultz@linaro.org>
> LKML-Reference: <4501cddb99d555624baade4609030ca458dfa3a0.1296124770.git.richard.cochran@omicron.at>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <johnstul@us.ibm.com>
^ permalink raw reply
* Re: Bootable Raid-1
From: Naira Kaieski @ 2011-02-01 21:35 UTC (permalink / raw)
To: lrhorer; +Cc: linux-raid
In-Reply-To: <8B.08.07087.360784D4@cdptpa-omtalb.mail.rr.com>
Hi,
My metadata is 0.90...
My Partitions:
/dev/sda1 1 122 979933+ fd Linux raid
autodetect
/dev/sda2 * 123 134 96390 fd Linux raid
autodetect
/dev/sda3 135 19457 155211997+ fd Linux raid
autodetect
Disk /dev/md1: 1003 MB, 1003356160 bytes
2 heads, 4 sectors/track, 244960 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/md1 doesn't contain a valid partition table
Disk /dev/md2: 98 MB, 98631680 bytes
2 heads, 4 sectors/track, 24080 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/md2 doesn't contain a valid partition table
Disk /dev/md3: 158.9 GB, 158936989696 bytes
2 heads, 4 sectors/track, 38802976 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc4036374
Disk /dev/md3 doesn't contain a valid partition table
I created the array with the command:
mdadm --create --verbose --assume-clean --metadata=0.90 /dev/md3
--level=1 --raid-devices=2 /dev/sda3 missing
# cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sda3[0]
155211904 blocks [2/1] [U_]
md2 : active raid1 sda2[0]
96320 blocks [2/1] [U_]
md1 : active raid1 sda1[0]
979840 blocks [2/1] [U_]
# mdadm -D --scan
ARRAY /dev/md1 metadata=0.90 UUID=e905069f:43e2eaa4:e090bcab:b1d9c206
ARRAY /dev/md2 metadata=0.90 UUID=d259ec4f:1c63d0b1:e090bcab:b1d9c206
ARRAY /dev/md3 metadata=0.90 UUID=030d5ded:82314c21:e090bcab:b1d9c206
On dmesg:
[ 2349.760155] md: bind<sda1>
[ 2349.762677] md/raid1:md1: active with 1 out of 2 mirrors
[ 2349.762720] md1: detected capacity change from 0 to 1003356160
[ 2349.765307] md1: unknown partition table
[ 2363.059235] md: bind<sda2>
[ 2363.061089] md/raid1:md2: active with 1 out of 2 mirrors
[ 2363.061129] md2: detected capacity change from 0 to 98631680
[ 2363.065812] md2: unknown partition table
[ 2372.302358] md: bind<sda3>
[ 2372.304614] md/raid1:md3: active with 1 out of 2 mirrors
[ 2372.304663] md3: detected capacity change from 0 to 158936989696
[ 2372.308395] md3: unknown partition table
My kernel config:
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
CONFIG_MD_RAID1=y
# mdadm --examine /dev/sda3
/dev/sda3:
Magic : a92b4efc
Version : 0.90.00
UUID : 030d5ded:82314c21:e090bcab:b1d9c206 (local to host dns)
Creation Time : Tue Feb 1 19:03:30 2011
Raid Level : raid1
Used Dev Size : 155211904 (148.02 GiB 158.94 GB)
Array Size : 155211904 (148.02 GiB 158.94 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 3
Update Time : Tue Feb 1 19:18:56 2011
State : clean
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0
Checksum : 64a5bec0 - correct
Events : 7
Number Major Minor RaidDevice State
this 0 8 3 0 active sync /dev/sda3
0 0 8 3 0 active sync /dev/sda3
1 1 0 0 1 faulty removed
I format the md* devices and copy file with rsync, alter the grub and
fstab to boot md devices but on boot i have fail to boot md3 as rootfs
Atenciosamente,
Naira Kaieski
Em 1/2/2011 18:43, Leslie Rhorer escreveu:
>> I have read several articles on the internet and researched in the
>> messages list, but I'm still having trouble configuring a raid level 1
>> array that is bootable.
>>
>> I configured a server some time agowith Gentoo Linux, Kernel
>> 2.6.28-hardened-r9, mdadm - v3.0 and 2 IDE hard drives, this is working
>> correctly. For this installation iused as a basis for consultation
>> Article http://en.gentoo-wiki.com/wiki/Migrate_to_RAID
>>
>> Now, I want to use two SATA drives in raid level 1,
>>
>> Now i have Gentoo Linux with kernel 2.6.36-hardened-r6 and mdadm -
>> v3.1.4 and the instructions of Article dont work. The kernel was
>> configured with support for disks raid autodetect and supported the raid
>> level 1. But in the logs of dmesg does not run the auto-detection of the
>> disks to the array, so in the boot when mounting the root device /
>> dev/md2 the system can not find the device.
>>
>> When I run mdadm - auto-detect the array are found somewhere but still
>> displays message indicating that the raid device is not a valid
>> partition table.
>>
>> How can you configure a raid level 1 with bootable disks / dev / sda and
>> / dev / sdb?
>> I want three partitions:
>> /dev/md1 - swap - /dev/sda1, /dev/sdb1
>> /dev/md2 - boot - /dev/sda2, /dev/sdb2
>> /dev/md3 - / - /dev/sda3, /dev/sdb3
>>
>> I am using grub as bootloader.
> This is very similar to my boot configuration on my two servers. I
> suspect your problem is the metadata. What version of superblock are you
> using for /dev/md2? GRUB2 does not recognize a version 1.x superblock.
> Since the boot images are quite small, and don't require an array of many
> disks, there is nothing wrong with the 0.90 superblock, however. If your
> /dev/md2 array is not a 0.9 version superblock, try converting it. Here is
> my configuration from one of the servers:
>
> ARRAY /dev/md0 level=raid6 num-devices=10 metadata=01.2 name=Backup:0
> UUID=431244d6:45d9635a:e88b3de5:92f30255
> ARRAY /dev/md1 level=raid1 num-devices=2 metadata=0.90
> UUID=4cde286c:0687556a:4d9996dd:dd23e701
> ARRAY /dev/md2 level=raid1 num-devices=2 metadata=01.2 name=Backup:2
> UUID=d45ff663:9e53774c:6fcf9968:21692025
> ARRAY /dev/md3 level=raid1 num-devices=2 metadata=01.2 name=Backup:3
> UUID=51d22c47:10f58974:0b27ef04:5609d357
>
> Where md0 is a large (11T) data array, md1 is boot, md2 is root, and
> md3 is swap. The partitioning layout of the boot drives is the same as
> yours.
>
^ permalink raw reply
* Re: [patch 25/28] posix clocks: Introduce a syscall for clock tuning.
From: john stultz @ 2011-02-01 21:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra, Alan Cox,
Arnd Bergmann, Christoph Lameter, David Miller, Krzysztof Halasa,
Rodolfo Giometti, Benjamin Herrenschmidt, Mike Frysinger,
Paul Mackerras, Russell King
In-Reply-To: <20110201134419.869804645@linutronix.de>
On Tue, 2011-02-01 at 13:52 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (posix-clocks-introduce-a-syscall-for-clock-tuning.patch)
> From: Richard Cochran <richardcochran@gmail.com>
>
> A new syscall is introduced that allows tuning of a POSIX clock. The
> new call, clock_adjtime, takes two parameters, the clock ID and a
> pointer to a struct timex. Any ADJTIMEX(2) operation may be requested
> via this system call, but various POSIX clocks may or may not support
> tuning.
>
> [ tglx: Adapted to the posix-timer cleanup series. Avoid copy_to_user
> in the error case ]
Acked-by: John Stultz <johnstul@us.ibm.com>
^ permalink raw reply
* Re: [PATCH 04/11] xen/mmu: BUG_ON when racing to swap middle leaf.
From: Jeremy Fitzhardinge @ 2011-02-01 21:34 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-kernel, Xen-devel, konrad, hpa, stefano.stabellini,
Ian.Campbell
In-Reply-To: <1296513876-31415-5-git-send-email-konrad.wilk@oracle.com>
On 01/31/2011 02:44 PM, Konrad Rzeszutek Wilk wrote:
> The initial bootup code uses set_phys_to_machine quite a lot, and after
> bootup it would be used by the balloon driver. The balloon driver does have
> mutex lock so this should not be necessary - but just in case, add
> a BUG_ON if we do hit this scenario.
>
> [v2: Change from WARN to BUG_ON]
> [v3: Rebased on top of xen->p2m code split]
> Reviewed-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> arch/x86/xen/p2m.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 19b0a65..fbbd2ab 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -478,7 +478,8 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>
> /* Swap over from MISSING to IDENTITY if needed. */
> if (p2m_top[topidx][mididx] == p2m_missing) {
> - p2m_top[topidx][mididx] = p2m_identity;
> + BUG_ON(cmpxchg(&p2m_top[topidx][mididx], p2m_missing,
> + p2m_identity) != p2m_missing);
Don't put side-effects in BUG_ONs. Why is it a bug anyway?
J
^ permalink raw reply
* Re: Codecs without auto-parser (was: ALSA: HDA: Fix microphone(s) on Lenovo Edge 13)
From: Takashi Iwai @ 2011-02-01 21:34 UTC (permalink / raw)
To: David Henningsson; +Cc: ALSA Development Mailing List
In-Reply-To: <4D47B835.7090502@canonical.com>
At Tue, 01 Feb 2011 08:37:25 +0100,
David Henningsson wrote:
>
> On 2011-01-28 13:10, Takashi Iwai wrote:
> > At Fri, 28 Jan 2011 12:51:30 +0100,
> > David Henningsson wrote:
> >>
> >> On 2011-01-28 09:01, Takashi Iwai wrote:
> >>> And I hope that we should go further a bit for now -- more clean up of
> >>> the cxt5066 code either checking BIOS pins or hp/mic/spk pre-defined
> >>> pins. Currently, the code is fairly messy (partly because of olpc
> >>> support), and now is a good chance to improve it a bit more.
> >>
> >> Maybe so. I'm not sure I can commit to doing that work right now, as I
> >> have other work commitments waiting for me to take care of them.
> >
> > OK.
>
> Hmm. I got a few things cleared up yesterday, and so I might have some
> time to actually do this.
Great.
> However, it also seems like I have to fix an
> AD1984A machine, and that driver is in equally bad shape (as in: no
> auto-parser, just a list of models).
Yeah, I know...
> I could add another model, but
> suppose I'd do this the right way, how would I do it?
>
> I guess there are three options to start off with:
>
> 1) ad1988 seems to have an auto-parser. There are a lot of hardcoded
> nids in there, but I guess I could copy-and-paste some into a new
> auto-parser for ad1984a.
Well... AD1988 and AD1984A aren't so similar, IIRC.
AD1984A is more straightforward hardware implementation while AD1988
can have more connections. Also AD1988 auto-parser isn't in the best
form in comparison with other codecs.
That being said, if AD1984A can fit with AD1988's auto-parser (i.e.
my memory was too vague), it's fine. We can adapt it.
If this is hard, one more quirk model won't be too bad for AD1984A
since this is a pretty simple codec, and there won't be so more devices
with this old chip.
> 2) It seems to me like the most competent candidate for auto-parser
> currently is the cx_auto stuff - compared to other auto-parsers the
> hardcoded nids are fewer. Perhaps this one could be extended to also do
> auto-parsing for codecs from other vendors? Or at least some convenience
> functions moved to hda_codec.c in order to remove duplication between
> vendors?
Yes, I can loudly tell people "I have a dream, unify all codec parsers!" :)
But, I'm afraid that a big hammer doesn't work. The topology is fairly
different between codecs, and resolving all makes the parser complex.
So, some hints would be needed to simplify the logic, after all.
> 3) There is also the generic parser. It seems to be the one most capable
> of handling randomly complex graphs, but is lacking automute/jack-detect
> support, and maybe other functions as well (?).
The generic parser is the very first parser, and it never worked rightly.
This should be really replaced with a more clever one.
thanks,
Takashi
^ permalink raw reply
* Re: [patch 20/28] posix-timers: Make posix-cpu-timers functions static
From: Thomas Gleixner @ 2011-02-01 21:33 UTC (permalink / raw)
To: John Stultz; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <1296595690.3336.66.camel@work-vm>
On Tue, 1 Feb 2011, John Stultz wrote:
> On Tue, 2011-02-01 at 13:52 +0000, Thomas Gleixner wrote:
> > plain text document attachment
> > (posix-timer-make-posix-cpu-timer-functions-static.patch)
> > All functions are accessed via clock_posix_cpu now. So make them static.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Cc: John Stultz <john.stultz@linaro.org>
> > Cc: Richard Cochran <richard.cochran@omicron.at>
>
> This patch seems to have more then just making functions static in it.
>
> > @@ -1481,68 +1483,67 @@ static int do_cpu_nanosleep(const clocki
> > return error;
> > }
> >
> > -int posix_cpu_nsleep(const clockid_t which_clock, int flags,
> > - struct timespec *rqtp, struct timespec __user *rmtp)
> > +static long posix_cpu_nsleep_restart(struct restart_block *restart_block)
> > {
> > - struct restart_block *restart_block =
> > - ¤t_thread_info()->restart_block;
> > + clockid_t which_clock = restart_block->nanosleep.index;
> > + struct timespec t;
> > struct itimerspec it;
> > int error;
> >
> > - /*
> > - * Diagnose required errors first.
> > - */
> > - if (CPUCLOCK_PERTHREAD(which_clock) &&
> > - (CPUCLOCK_PID(which_clock) == 0 ||
> > - CPUCLOCK_PID(which_clock) == current->pid))
> > - return -EINVAL;
> > + t = ns_to_timespec(restart_block->nanosleep.expires);
> >
> > - error = do_cpu_nanosleep(which_clock, flags, rqtp, &it);
> > + error = do_cpu_nanosleep(which_clock, TIMER_ABSTIME, &t, &it);
> >
> > if (error == -ERESTART_RESTARTBLOCK) {
> > -
> > - if (flags & TIMER_ABSTIME)
> > - return -ERESTARTNOHAND;
> > + struct timespec __user *rmtp = restart_block->nanosleep.rmtp;
> > /*
> > * Report back to the user the time still remaining.
> > */
> > if (rmtp && copy_to_user(rmtp, &it.it_value, sizeof *rmtp))
> > return -EFAULT;
> >
> > - restart_block->fn = posix_cpu_nsleep_restart;
> > - restart_block->nanosleep.index = which_clock;
> > - restart_block->nanosleep.rmtp = rmtp;
> > - restart_block->nanosleep.expires = timespec_to_ns(rqtp);
> > + restart_block->nanosleep.expires = timespec_to_ns(&t);
> > }
> > return error;
> > +
> > }
> >
> > -long posix_cpu_nsleep_restart(struct restart_block *restart_block)
> > +static int posix_cpu_nsleep(const clockid_t which_clock, int flags,
> > + struct timespec *rqtp, struct timespec __user *rmtp)
> > {
> > - clockid_t which_clock = restart_block->nanosleep.index;
> > - struct timespec t;
> > + struct restart_block *restart_block =
> > + ¤t_thread_info()->restart_block;
> > struct itimerspec it;
> > int error;
> >
> > - t = ns_to_timespec(restart_block->nanosleep.expires);
> > + /*
> > + * Diagnose required errors first.
> > + */
> > + if (CPUCLOCK_PERTHREAD(which_clock) &&
> > + (CPUCLOCK_PID(which_clock) == 0 ||
> > + CPUCLOCK_PID(which_clock) == current->pid))
> > + return -EINVAL;
> >
> > - error = do_cpu_nanosleep(which_clock, TIMER_ABSTIME, &t, &it);
> > + error = do_cpu_nanosleep(which_clock, flags, rqtp, &it);
> >
> > if (error == -ERESTART_RESTARTBLOCK) {
> > - struct timespec __user *rmtp = restart_block->nanosleep.rmtp;
> > +
> > + if (flags & TIMER_ABSTIME)
> > + return -ERESTARTNOHAND;
> > /*
> > * Report back to the user the time still remaining.
> > */
> > if (rmtp && copy_to_user(rmtp, &it.it_value, sizeof *rmtp))
> > return -EFAULT;
> >
> > - restart_block->nanosleep.expires = timespec_to_ns(&t);
> > + restart_block->fn = posix_cpu_nsleep_restart;
> > + restart_block->nanosleep.index = which_clock;
> > + restart_block->nanosleep.rmtp = rmtp;
> > + restart_block->nanosleep.expires = timespec_to_ns(rqtp);
> > }
> > return error;
> > -
> > }
>
> Maybe split that out?
I just moved the restart function above nanosleep to avoid the forward
declaration, but patch deciced to make it more complex. I'll stick
with the forward declaration.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 02/11] xen/mmu: Add the notion of identity (1-1) mapping.
From: Jeremy Fitzhardinge @ 2011-02-01 21:33 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-kernel, Xen-devel, konrad, hpa, stefano.stabellini,
Ian.Campbell
In-Reply-To: <1296513876-31415-3-git-send-email-konrad.wilk@oracle.com>
On 01/31/2011 02:44 PM, Konrad Rzeszutek Wilk wrote:
> Our P2M tree structure is a three-level. On the leaf nodes
> we set the Machine Frame Number (MFN) of the PFN. What this means
> is that when one does: pfn_to_mfn(pfn), which is used when creating
> PTE entries, you get the real MFN of the hardware. When Xen sets
> up a guest it initially populates a array which has descending
> (or ascending) MFN values, as so:
>
> idx: 0, 1, 2
> [0x290F, 0x290E, 0x290D, ..]
>
> so pfn_to_mfn(2)==0x290D. If you start, restart many guests that list
> starts looking quite random.
>
> We graft this structure on our P2M tree structure and stick in
> those MFN in the leafs. But for all other leaf entries, or for the top
> root, or middle one, for which there is a void entry, we assume it is
> "missing". So
> pfn_to_mfn(0xc0000)=INVALID_P2M_ENTRY.
>
> We add the possibility of setting 1-1 mappings on certain regions, so
> that:
> pfn_to_mfn(0xc0000)=0xc0000
>
> The benefit of this is, that we can assume for non-RAM regions (think
> PCI BARs, or ACPI spaces), we can create mappings easily b/c we
> get the PFN value to match the MFN.
>
> For this to work efficiently we introduce one new page p2m_identity and
> allocate (via reserved_brk) any other pages we need to cover the sides
> (1GB or 4MB boundary violations). All entries in p2m_identity are set to
> INVALID_P2M_ENTRY type (Xen toolstack only recognizes that and MFNs,
> no other fancy value).
>
> On lookup we spot that the entry points to p2m_identity and return the identity
> value instead of dereferencing and returning INVALID_P2M_ENTRY. If the entry
> points to an allocated page, we just proceed as before and return the PFN.
> If the PFN has IDENTITY_FRAME_BIT set we unmask that in appropriate functions
> (pfn_to_mfn).
>
> The reason for having the IDENTITY_FRAME_BIT instead of just returning the
> PFN is that we could find ourselves where pfn_to_mfn(pfn)==pfn for a
> non-identity pfn. To protect ourselves against we elect to set (and get) the
> IDENTITY_FRAME_BIT on all identity mapped PFNs.
>
> This simplistic diagram is used to explain the more subtle piece of code.
> There is also a digram of the P2M at the end that can help.
> Imagine your E820 looking as so:
>
> 1GB 2GB
> /-------------------+---------\/----\ /----------\ /---+-----\
> | System RAM | Sys RAM ||ACPI| | reserved | | Sys RAM |
> \-------------------+---------/\----/ \----------/ \---+-----/
> ^- 1029MB ^- 2001MB
>
> [1029MB = 263424 (0x40500), 2001MB = 512256 (0x7D100), 2048MB = 524288 (0x80000)]
>
> And dom0_mem=max:3GB,1GB is passed in to the guest, meaning memory past 1GB
> is actually not present (would have to kick the balloon driver to put it in).
>
> When we are told to set the PFNs for identity mapping (see patch: "xen/setup:
> Set identity mapping for non-RAM E820 and E820 gaps.") we pass in the start
> of the PFN and the end PFN (263424 and 512256 respectively). The first step is
> to reserve_brk a top leaf page if the p2m[1] is missing. The top leaf page
> covers 512^2 of page estate (1GB) and in case the start or end PFN is not
> aligned on 512^2*PAGE_SIZE (1GB) we loop on aligned 1GB PFNs from start pfn to
> end pfn. We reserve_brk top leaf pages if they are missing (means they point
> to p2m_mid_missing).
>
> With the E820 example above, 263424 is not 1GB aligned so we allocate a
> reserve_brk page which will cover the PFNs estate from 0x40000 to 0x80000.
> Each entry in the allocate page is "missing" (points to p2m_missing).
>
> Next stage is to determine if we need to do a more granular boundary check
> on the 4MB (or 2MB depending on architecture) off the start and end pfn's.
> We check if the start pfn and end pfn violate that boundary check, and if
> so reserve_brk a middle (p2m[x][y]) leaf page. This way we have a much finer
> granularity of setting which PFNs are missing and which ones are identity.
> In our example 263424 and 512256 both fail the check so we reserve_brk two
> pages. Populate them with INVALID_P2M_ENTRY (so they both have "missing" values)
> and assign them to p2m[1][2] and p2m[1][488] respectively.
>
> At this point we would at minimum reserve_brk one page, but could be up to
> three. Each call to set_phys_range_identity has at maximum a three page
> cost. If we were to query the P2M at this stage, all those entries from
> start PFN through end PFN (so 1029MB -> 2001MB) would return INVALID_P2M_ENTRY
> ("missing").
>
> The next step is to walk from the start pfn to the end pfn setting
> the IDENTITY_FRAME_BIT on each PFN. This is done in '__set_phys_to_machine'.
> If we find that the middle leaf is pointing to p2m_missing we can swap it over
> to p2m_identity - this way covering 4MB (or 2MB) PFN space. At this point we
> do not need to worry about boundary aligment (so no need to reserve_brk a middle
> page, figure out which PFNs are "missing" and which ones are identity), as that
> has been done earlier. If we find that the middle leaf is not occupied by
> p2m_identity or p2m_missing, we dereference that page (which covers
> 512 PFNs) and set the appropriate PFN with IDENTITY_FRAME_BIT. In our example
> 263424 and 512256 end up there, and we set from p2m[1][2][256->511] and
> p2m[1][488][0->256] with IDENTITY_FRAME_BIT set.
>
> All other regions that are void (or not filled) either point to p2m_missing
> (considered missing) or have the default value of INVALID_P2M_ENTRY (also
> considered missing). In our case, p2m[1][2][0->255] and p2m[1][488][257->511]
> contain the INVALID_P2M_ENTRY value and are considered "missing."
>
> This is what the p2m ends up looking (for the E820 above) with this
> fabulous drawing:
>
> p2m /--------------\
> /-----\ | &mfn_list[0],| /-----------------\
> | 0 |------>| &mfn_list[1],| /---------------\ | ~0, ~0, .. |
> |-----| | ..., ~0, ~0 | | ~0, ~0, [x]---+----->| IDENTITY [@256] |
> | 1 |---\ \--------------/ | [p2m_identity]+\ | IDENTITY [@257] |
> |-----| \ | [p2m_identity]+\\ | .... |
> | 2 |--\ \-------------------->| ... | \\ \----------------/
> |-----| \ \---------------/ \\
> | 3 |\ \ \\ p2m_identity
> |-----| \ \-------------------->/---------------\ /-----------------\
> | .. +->+ | [p2m_identity]+-->| ~0, ~0, ~0, ... |
> \-----/ / | [p2m_identity]+-->| ..., ~0 |
> / /---------------\ | .... | \-----------------/
> / | IDENTITY[@0] | /-+-[x], ~0, ~0.. |
> / | IDENTITY[@256]|<----/ \---------------/
> / | ~0, ~0, .... |
> | \---------------/
> |
> p2m_missing p2m_missing
> /------------------\ /------------\
> | [p2m_mid_missing]+---->| ~0, ~0, ~0 |
> | [p2m_mid_missing]+---->| ..., ~0 |
> \------------------/ \------------/
>
> where ~0 is INVALID_P2M_ENTRY. IDENTITY is (PFN | IDENTITY_BIT)
>
> [v4: Squished patches in just this one]
> [v5: Changed code to use ranges, added ASCII art]
> [v6: Rebased on top of xen->p2m code split]
> [v7: Added RESERVE_BRK for potentially allocated pages]
> [v8: Fixed alignment problem]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> arch/x86/include/asm/xen/page.h | 6 ++-
> arch/x86/xen/p2m.c | 109 ++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 112 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 8ea9772..47c1b59 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -30,7 +30,9 @@ typedef struct xpaddr {
> /**** MACHINE <-> PHYSICAL CONVERSION MACROS ****/
> #define INVALID_P2M_ENTRY (~0UL)
> #define FOREIGN_FRAME_BIT (1UL<<31)
> +#define IDENTITY_FRAME_BIT (1UL<<30)
These need to be BITS_PER_LONG-1 and -2.
J
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-01 21:32 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <20110201212411.GD30770@redhat.com>
On Tue, 2011-02-01 at 23:24 +0200, Michael S. Tsirkin wrote:
> My theory is that the issue is not signalling.
> Rather, our queue fills up, then host handles
> one packet and sends an interrupt, and we
> immediately wake the queue. So the vq
> once it gets full, stays full.
>From the printk debugging output, it might not be exactly the case. The
ring gets full, run a bit, then gets full, then run a bit, then full...
> If you try my patch with bufs threshold set to e.g.
> half the vq, what we will do is send interrupt after we have processed
> half the vq. So host has half the vq to go, and guest has half the vq
> to fill.
>
> See?
I am cleaning up my set up to run your patch ...
Shirley
^ permalink raw reply
* Re: [PATCH] ASoC: Amstrad Delta: fix NULL pointer dereference
From: Mark Brown @ 2011-02-01 21:33 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: alsa-devel, Liam Girdwood
In-Reply-To: <201102011840.55512.jkrzyszt@tis.icnet.pl>
On Tue, Feb 01, 2011 at 06:40:55PM +0100, Janusz Krzysztofik wrote:
> It looks like the .card member of the snd_soc_pcm_runtime structure
> pointed to by the snd_soc_dai_link.init() argument is no longer
> initialized before the function being called. As the Amstrad Delta sound
> card driver was making use of it for locating its snd_soc_card
> structure, this resulted in actual or potential NULL pointer
> dereferences.
Seems like it'd be better to fix this in the core - this is a reasonable
thing to want to have set up and the use ams-delta makes of it seems
perfectly sensible. Care to do a patch?
^ permalink raw reply
* Re: OE TSC
From: Bernhard Guillon @ 2011-02-01 21:31 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <AANLkTi=KqA0bXAbuu8VDJz14L9DiHguRLNYWth1R6wMY@mail.gmail.com>
On 01.02.2011 21:08, Frans Meulenbroeks wrote:
> ... a team that
> is chosen by the community is much more empowered to make decisions.
>
+1
In my opinion it is very important in the current situation to have a vote.
best regards
Bernhard Guillon
^ permalink raw reply
* [U-Boot] PCIE supported networking cards?
From: Aaron Williams @ 2011-02-01 21:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20110201131924.48242619@udp111988uds.am.freescale.net>
This is an Intel EXPI9301 PRO/1000 OEM card, vendor ID 0x8086, device ID
0x10d3. I added it to the list but I don't know what the MAC type is. I'll
look into the Linux driver and see if I can see what it is.
-Aaron
On Tuesday, February 01, 2011 11:19:24 am Scott Wood wrote:
> On Tue, 1 Feb 2011 13:15:01 -0600
>
> Kumar Gala <galak@kernel.crashing.org> wrote:
> > We utilize e1000 PCIe cards all the time
>
> Aren't there some versions that work, and some that don't?
>
> -Scott
>
> > - k
> >
> > On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote:
> > > Are there any PCIE networking cards that are supported? So far I've
> > > tried an Intel card and a Realtek RTL8168 card, but neither is
> > > supported. It looks like the E1000 driver only supports PCI and PCIX
> > > based cards (Linux uses the e1000e card for PCIe cards).
> > >
> > > -Aaron
> > > _______________________________________________
> > > U-Boot mailing list
> > > U-Boot at lists.denx.de
> > > http://lists.denx.de/mailman/listinfo/u-boot
> >
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply
* Re: [patch] xfsprogs: repair pagefault due to missed out sanity NULL check
From: Christoph Hellwig @ 2011-02-01 21:34 UTC (permalink / raw)
To: Ajeet Yadav; +Cc: xfs
In-Reply-To: <AANLkTinKMEzgmnNLQowSToVY45HJYBY2ktipAf9DE3pB@mail.gmail.com>
Thanks, applied.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [patch 24/28] posix-clocks: Splitout compat timex accessors
From: john stultz @ 2011-02-01 21:31 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110201134419.772343089@linutronix.de>
On Tue, 2011-02-01 at 13:52 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (posix-clocks-splitout-compat-timex-accessors.patch)
> From: Richard Cochran <richardcochran@gmail.com>
>
> Split out the compat timex accessors into separate
> functions. Preparatory patch for a new syscall.
>
> [ tglx: Split that patch from Richards "posix clocks: Introduce a
> syscall for clock tuning.". Keeps the changes strictly
> separate ]
>
> Originally-from: Richard Cochran <richardcochran@gmail.com>
> Cc: John Stultz <john.stultz@linaro.org>
> LKML-Reference: <2d5e2f3e6f388aa1848d40406646aab2e26a906f.1296124770.git.richard.cochran@omicron.at>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <johnstul@us.ibm.com>
^ permalink raw reply
* Re: Odd "data used" reporting behavior by ceph -w
From: Jim Schutt @ 2011-02-01 21:31 UTC (permalink / raw)
To: Gregory Farnum; +Cc: ceph-devel@vger.kernel.org
In-Reply-To: <AANLkTi=wo0LxhsKTSpRAMRc=Owb6wfV3D8=fYTxR+BMR@mail.gmail.com>
Hi Greg,
On Fri, 2011-01-28 at 17:44 -0700, Gregory Farnum wrote:
> Jim:
> It's been a while, but I started looking into this again a couple days
> ago.
Great, thanks.
> The file deletion being slow is something we've decided to push
> back after 1.0, since it doesn't really seem like a serious issue. The
> other two problems we wanted to solve, though, and I think we've
> succeeded. I was unable to reproduce your problem with ls on recent
> branches, and just pushed a fix for the slow dd-truncate-dd to both
> the master and stable branches. When you get the chance, please test
> one of those out and let me know if you still see issues like this.
I've just lightly tested current stable branch, commit 0f3198e8c63.
For me both problems seem to still exist.
I'm running 4 osds per host on 4 hosts, 1 mon, 1 mds, 64 clients.
For me a "ls" on the file system root from one of
the clients still doesn't complete until the dd commands
running on each client complete.
Also, it is still true for me if I truncate all the files
to zero from one of the clients, then write them again,
one file per client, that second set of writes goes very
slow.
Am I maybe testing the wrong commit?
-- Jim
> Thanks!
> -Greg
>
> On Tue, Dec 7, 2010 at 7:14 AM, Jim Schutt <jaschut@sandia.gov> wrote:
> >
> > Hi Sage,
> >
> > On Sat, 2010-12-04 at 21:59 -0700, Sage Weil wrote:
> >> Hi Jim,
> >>
> >> I think there are at least two different things going on here.
> >>
> >> On Fri, 3 Dec 2010, Jim Schutt wrote:
> >> > On Fri, 2010-12-03 at 15:36 -0700, Gregory Farnum wrote:
> >> > > How are you generating these files? It sounds like maybe you're
> >> doing
> >> > > them concurrently on a bunch of clients?
> >> >
> >> > When I created the files initially, I did it via one
> >> > dd per client over 64 clients, all at the same time.
> >> >
> >> > When I used echo to truncate them to zero length, I
> >> > did all files from one client. Also, when I removed
> >> > the files, I did them all from a single client.
> >>
> >> The MDS doesn't release objects on deleted files until all references
> >> to
> >> the file go away (i.e. everyone closes the file handle). The client
> >> make
> >> a point of releasing it's capability on inodes it unlinks, but since
> >> the
> >> unlink happened on a different node, the writer doesn't realize it's
> >> unlinked and doesn't bother to release its capability (until it gets
> >> pushed out of the inode cache due to normal cache pressure). I
> >> suspect
> >> this will need some additional messaging to get the client to drop it
> >> sooner.
> >>
> >> http://tracker.newdream.net/issues/630
> >>
> >> That fix won't make it into 0.24, sorry! Probably 0.24.1.
> >>
> >
> > Thanks for tracking this! Whatever priority you assign
> > works great for me.
> >
> > -- Jim
> >
> >
> >
> >
> >
>
^ permalink raw reply
* Re: [patch 23/28] ntp: Add ADJ_SETOFFSET mode bit
From: john stultz @ 2011-02-01 21:30 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110201134419.679485268@linutronix.de>
On Tue, 2011-02-01 at 13:52 +0000, Thomas Gleixner wrote:
> plain text document attachment (ntp-add-adj_setoffset-mode-bit.patch)
> From: Richard Cochran <richardcochran@gmail.com>
>
> This patch adds a new mode bit into the timex structure. When set, the bit
> instructs the kernel to add the given time value to the current time.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> Cc: John Stultz <john.stultz@linaro.org>
> LKML-Reference: <2f7ed6bce83c23e4b7e4530794f0aa175df31a39.1296124770.git.richard.cochran@omicron.at>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <johnstul@us.ibm.com>
^ permalink raw reply
* [Buildroot] [PATCH] Makefile.package.in: fix upper case $(PKG)_SITE_METHOD
From: Bjørn Forsman @ 2011-02-01 21:30 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20110201213433.1d527342@surf>
On 1 February 2011 21:34, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Tue, ?1 Feb 2011 12:18:49 +0100
> Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:
>
>> ? ? ? ? ? ? ? case "$($(PKG)_SITE_METHOD)" in \
>> - ? ? ? ? ? ? ? ? ? ? git) $($(DL_MODE)_GIT) && exit ;; \
>> - ? ? ? ? ? ? ? ? ? ? svn) $($(DL_MODE)_SVN) && exit ;; \
>> - ? ? ? ? ? ? ? ? ? ? bzr) $($(DL_MODE)_BZR) && exit ;; \
>> + ? ? ? ? ? ? ? ? ? ? GIT) $($(DL_MODE)_GIT) && exit ;; \
>> + ? ? ? ? ? ? ? ? ? ? SVN) $($(DL_MODE)_SVN) && exit ;; \
>> + ? ? ? ? ? ? ? ? ? ? BZR) $($(DL_MODE)_BZR) && exit ;; \
>> ? ? ? ? ? ? ? ? ? ? ? *) $(call $(DL_MODE)_WGET,$(1),$(2)) && exit ;; \
>> ? ? ? ? ? ? ? esac ; \
>> ? ? ? fi ; \
>
> No. This is going to break:
>
> ? ? ? ?# Try automatic detection using the scheme part of the URI
> ? ? ? ?$(2)_SITE_METHOD = $(firstword $(subst ://, ,$(call qstrip,$($(2)_SITE))))
>
> is used to detect the site method from the URI, like :
>
> ? ? ? ?git://....
>
> or
>
> ? ? ? ?svn://....
>
> so if only upper case site methods are accepted, it's not going to work.
Oh, didn't see that one.
> And more generally, I'd prefer to keep the existing lower-case writing
> of the site method, since it is coherent with how it's written in the
> URI.
How about my first patch then, allowing both upper and lower case (to
stay in sync with doc)? Or reword the doc?
Having doc != implementation is confusing so one of them should get patched :-)
^ permalink raw reply
* iMX31 MBX registers Porting problem
From: Chris @ 2011-02-01 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin+gjAzT+PbQx1bm2wxao58oynMGfW4MxXd6K-D@mail.gmail.com>
On Tue, Feb 1, 2011 at 2:05 PM, Chris <therealbadguy@gmail.com> wrote:
>> ?I have gone the extra distance in turning off support in the working kernel
>> 2.6.19.2, I have removed nearly everything. I am down to the gpio_port
>>
>
I was finally able to get this device to stop working on 2.6.19.2
it seems that a mapping is being done to the peripheral port register.
/* Setup Peripheral Port Remap register for AVIC */
asm("ldr r0, =0xC0000015 \n\
mcr p15, 0, r0, c15, c2, 4");
once this code is disabled, speaking to my device no longer returns
the expected results.
however, simply pasting this code in the new kernel does not
immediately bring me happiness.
this is from a fixup routine used in kernel 2.6.19.2, so I cloned that
logic and created a fixup routine.
I think perhaps that some other things have gotten in the way.
Are there any changes that would impact me here that anyone knows of?
my concern is now that there is not the only code enabling this
access, and I am trying to research that end of it.
I am pretty confident this is not device specific any more, but more
platform support.
I know noone is working on this device, but perhaps some experience
with this register will help.
I am amazed that all these chips are parked on the new kernel versions,
does anyone have any plans to ever work with this stuff?
I think we need this working. at least bring the support as far
forward as I can.
My Last post: Stupid fingers hit enter, so sorry guys. :(
^ permalink raw reply
* Re: [PATCH 3/3] vcs-svn: Refactor dump_export code into dispatch table
From: Junio C Hamano @ 2011-02-01 21:29 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, Git List, David Barr, Sverre Rabbelier
In-Reply-To: <20110201174241.GB3771@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Heh. I think that Junio was suggesting making the _parser_
> table-driven, meaning something like
>
> ... node_kinds[] = {
> { "100644", sizeof("100644"), "file" },
> ...
> };
Yes, and thanks.
^ permalink raw reply
* Re: [PATCH] t5526: Fix wrong argument order in "git config"
From: Junio C Hamano @ 2011-02-01 21:28 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git Mailing List, Libor Pechacek
In-Reply-To: <4D46E88D.1020806@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> This fixes a typo where the "git config" arguments "-f" and "--unset" were
> swapped leading to the creation of a "--unset" file.
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
> Now that 1.7.4 is out and somebody else already stumbled across this
> typo I introduced ...
Thanks.
>
> t/t5526-fetch-submodules.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t5526-fetch-submodules.sh b/t/t5526-fetch-submodules.sh
> index 884a5e5..a5f4585 100755
> --- a/t/t5526-fetch-submodules.sh
> +++ b/t/t5526-fetch-submodules.sh
> @@ -124,7 +124,7 @@ test_expect_success "--recurse-submodules overrides fetchRecurseSubmodules setti
> (
> cd downstream &&
> git fetch --recurse-submodules >../actual.out 2>../actual.err &&
> - git config -f --unset .gitmodules submodule.submodule.fetchRecurseSubmodules true &&
> + git config --unset -f .gitmodules submodule.submodule.fetchRecurseSubmodules &&
> git config --unset submodule.submodule.fetchRecurseSubmodules
> ) &&
> test_cmp expect.out actual.out &&
> --
> 1.7.3.4.27.g3921d.dirty
^ 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.