* Re: MD/DM and barriers (was Re: [patch] ext2/3: document conditions when reliable operation is possible)
From: Alasdair G Kergon @ 2009-08-27 18:09 UTC (permalink / raw)
To: Jeff Garzik
Cc: Ric Wheeler, Theodore Tso, Rob Landley, Pavel Machek,
Florian Weimer, Goswin von Brederlow, kernel list, Andrew Morton,
mtk.manpages, rdunlap, linux-doc, linux-ext4, corbet,
Mikulas Patocka
In-Reply-To: <4A96BA2D.60804@garzik.org>
On Thu, Aug 27, 2009 at 12:54:05PM -0400, Jeff Garzik wrote:
> DM has some barrier code... but the above code was pasted from DM's
> make_request function, so I am guessing that DM's barrier stuff is
> incomplete and disabled at present.
That code is from the new request-based multipath implementation in 2.6.31
which doesn't yet.
But bio-based dm does support barriers now. (Just missing some patches to
complete the dm-raid1 support that are still under review IIRC.)
Alasdair
^ permalink raw reply
* [Qemu-devel] Re: Breakage with local APIC routing
From: Jan Kiszka @ 2009-08-27 18:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: qemu-devel, Avi Kivity
In-Reply-To: <alpine.DEB.1.00.0908251535570.19140@intel-tinevez-2-302>
[-- Attachment #1: Type: text/plain, Size: 4464 bytes --]
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 25 Aug 2009, Jan Kiszka wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Tue, 25 Aug 2009, Jan Kiszka wrote:
>>>
>>>> Johannes Schindelin wrote:
>>>>
>>>>> On Sun, 17 Aug 2008, Jan Kiszka wrote:
>>>>>
>>>>>> Johannes Schindelin wrote:
>>>>>>
>>>>>>> On Wed, 13 Aug 2008, Jan Kiszka wrote:
>>>>>>>
>>>>>>>> Johannes Schindelin wrote:
>>>>>>>>> due to the change in revision 3371 (well, at that time, CVS was
>>>>>>>>> used, which was no better than Subversion) installation of win64
>>>>>>>>> is broken in QEmu. The commit message reads like this:
>>>>>>>>>
>>>>>>>>> Don't route PIC interrupts through the local APIC if the local
>>>>>>>>> APIC config says so. By Ari Kivity.
>>>>>>>> I recalled some earlier post on this which claimed to fix the issue
>>>>>>>> and found it in the archive:
>>>>>>>>
>>>>>>>> http://permalink.gmane.org/gmane.comp.emulators.qemu/25415
>>>>>>> I tried this, and it changes the symptoms, indeed. Instead of an
>>>>>>> endless loop, it results in a bluescreen.
>>>>>>>
>>>>>>> As the OP said that it worked for him, I guess it is either in
>>>>>>> commits that came after his post, or in my add-on patches.
>>>>>> So we are likely on the wrong path. Maybe we have to understand what
>>>>>> happens here first...
>>>>>>
>>>>>>> Hopefully I will find some time to work more on this bug.
>>>>>> Would be interesting to know
>>>>>> - if pic_irq_request is continuously called or if it stops when windows
>>>>>> hangs
>>>>>> - what IRQ vectors are delivered
>>>>>> - in what state the apic is, namely the s->lvt[APIC_LVT_LINT0]
>>>>> Sorry for the long delay. I just don't have time to take care of the
>>>>> issue, but I quickly verified that it still does not work, with aa0cba4
>>>>> (Aug 13 2009).
>>>>>
>>>>> If you are still interested in this issue, could you give me a hint
>>>>> _where_ I should output _which_ values? I'll gladly take time for that
>>>>> now.
>>>> If some OS does not properly install due to a possible emulation bug, I
>>>> am interested, for sure. Let's restart this by specifying the test case
>>>> more precisely: What version of Windows are you trying to install?
>>> As far as I remember, it is a plain version of 64-bit XP Pro. (Maybe it
>>> is a custom .iso for my day-job, but I think this is not the case).
>>>
>>>> What is your qemu command line?
>>> test -h pc-bios/keymaps || ln -s ../keymaps pc-bios/
>>>
>>> ./x86_64-softmmu/qemu-system-x86_64 \
>>> -L pc-bios/ \
>>> -m 1024 \
>>> -monitor stdio \
>>> -k en-us \
>>> -hda w64.img \
>>> -cdrom en_win_xp_pro_x64bit.iso \
>>> -fda fat:fat \
>>> -boot d \
>>> -net none \
>>> -localtime
>>>
>>>> Where does the installation fail?
>>> "Setup is starting Windows". (Just after "Setup is loading files (...)"
>>> phase.)
>>>
>>>> Are there specific steps required during the installation to reproduce
>>>> the problem?
>>> You need a 64-bit XP Pro, then call the command line as I did. It hangs
>>> at
>>>
>>> (qemu) info cpus
>>> * CPU #0: pc=0xfffff800010cabeb
>>>
>>> This is 100% reproducible.
>>>
>>>> And one more question: Did you check that you were using the
>>>> corresponding BIOS to aa0cba4?
>>> Yes, I always use -L pc-bios/ in the same Git working directory, and I
>>> just verified that indeed, the source is clean.
>>>
>>> A tiny, gentle reminder: the revision which is now available as 0e21e12b
>>> introduced this particular breakage.
>> OK, just found some 64-bit Windows ISO (Server 2003) that also makes no
>> progress at the point you described. Will play with it later today,
>> specifically with the LAPIC changes you referred to.
>
> Thank you very much!
>
> If you need me to test something, just let me know; I'll try to squeeze
> that into my time schedule.
I'm starting to get clueless about this issue. It looks like a timing
issue as I was able to crash Windows when using qemu-kvm (in kvm mode)
and attaching a guest debugger to the "right" spot. As you may know,
this also happens today (after dyngen to TCG switch) when resetting the
CPU interrupt in pic_irq_request on !level. To exclude that Windows is
simply fragile here, I need a better test case, ideally some with source
code. Think I will look into Mohammed's Ubuntu case again.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
^ permalink raw reply
* Re: [PATCH] rndis_wlan: increase scan timer delay
From: Jussi Kivilinna @ 2009-08-27 18:06 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-wireless, John W. Linville
In-Reply-To: <1251382153.11788.3.camel@localhost.localdomain>
Quoting "Dan Williams" <dcbw@redhat.com>:
> On Thu, 2009-08-27 at 13:43 +0300, Jussi Kivilinna wrote:
>> Please, don't merge this after all. Blocks scan too long and breaks
>> NetworkManager/wpa_supplicant.
>
> Hmm, it shouldn't. I've seen other cards (ath5k a/b/g) take 5 to 8
> seconds to scan when they scan all the bands. iwlwifi sometimes takes 5
> seconds to scan as well. That should all be valid.
>
You're right, increasing delay exposed bug that caused reconnects.
With short delay (re)scans didn't block so long and connection was
established faster. With 6 sec connection was established eventually.
I'll send bug fix (workaround really, hw sometimes sends extra media
connect events when setting WPA keys, which needs to be ignored) and
resend this patch in two patch set after more testing.
-Jussi
^ permalink raw reply
* Re: [patch 6/9] acpi: don't free non-existent backlight in acpi video module
From: Len Brown @ 2009-08-27 18:05 UTC (permalink / raw)
To: akpm; +Cc: linux-acpi, keithp, rui.zhang
In-Reply-To: <200908062257.n76Mvs1F024250@imap1.linux-foundation.org>
Applied for 2.6.31
thanks,
Len Brown, Intel Open Source Technology Center
On Thu, 6 Aug 2009, akpm@linux-foundation.org wrote:
> From: Keith Packard <keithp@keithp.com>
>
> acpi_video_put_one_device was attempting to remove sysfs entries and
> unregister a backlight device without first checking that said backlight
> device structure had been created.
>
> Signed-off-by: Keith Packard <keithp@keithp.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Len Brown <lenb@kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/acpi/video.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff -puN drivers/acpi/video.c~acpi-dont-free-non-existent-backlight-in-acpi-video-module drivers/acpi/video.c
> --- a/drivers/acpi/video.c~acpi-dont-free-non-existent-backlight-in-acpi-video-module
> +++ a/drivers/acpi/video.c
> @@ -2004,8 +2004,11 @@ static int acpi_video_bus_put_one_device
> status = acpi_remove_notify_handler(device->dev->handle,
> ACPI_DEVICE_NOTIFY,
> acpi_video_device_notify);
> - sysfs_remove_link(&device->backlight->dev.kobj, "device");
> - backlight_device_unregister(device->backlight);
> + if (device->backlight) {
> + sysfs_remove_link(&device->backlight->dev.kobj, "device");
> + backlight_device_unregister(device->backlight);
> + device->backlight = NULL;
> + }
> if (device->cdev) {
> sysfs_remove_link(&device->dev->dev.kobj,
> "thermal_cooling");
> _
>
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Brandon Casey @ 2009-08-27 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vr5uxrwld.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
>
>>> This seems to break t9001. Near the tip of 'pu' I have a iffy
>>> workaround.
>> Can you squash this into your 'iffy' workaround to help platforms
>> (Solaris 7, IRIX 6.5) without the 'yes' utility?
>
> Not in this form, for two reasons ;-)
>
> (1) t7610-mergetool.sh,also seems to use "yes". Perhaps define something
> in test-lib.sh?
>
> (2) The implementation is iffy.
Looks good, I'll rework it sometime if you don't beat me to it.
-brandon
>> +yes () {
>> + test -n "$*" && y="$*" || y='y'
>
> Shouldn't it be
>
> if test $# = 0
> then
> y=y
> else
> y="$*"
> fi
>
> so that
>
> yes ""
>
> would give runs of empty lines?
^ permalink raw reply
* Re: [Bug #14012] latest git fried my x86_64 imac
From: Justin P. Mattock @ 2009-08-27 18:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Peter Zijlstra,
Ingo Molnar
In-Reply-To: <200908262306.38464.rjw-KKrjLPT3xs0@public.gmane.org>
Rafael J. Wysocki wrote:
> On Wednesday 26 August 2009, Justin P. Mattock wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.30. Please verify if it still should be listed and let me know
>>> (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14012
>>> Subject : latest git fried my x86_64 imac
>>> Submitter : Justin P. Mattock<justinmattock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Date : 2009-08-13 07:20 (13 days old)
>>> References : http://marc.info/?l=linux-kernel&m=125014080427090&w=4
>>>
>>>
>>>
>>>
>>>
>> if I revert this commit:
>> af6af30c0fcd77e621638e53ef8b176bca8bd3b4
>> I can get a normal bootup.
>>
>
> Hm, that's
>
> commit af6af30c0fcd77e621638e53ef8b176bca8bd3b4
> Author: Peter Zijlstra<peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> Date: Wed Aug 5 20:41:04 2009 +0200
>
> ftrace: Fix perf-tracepoint OOPS
>
> I wonder what happens if you compile out ftrace?
>
>
>> As for this bug, it seems I'm the only
>> hitting this. The system is a fresh LFS build
>> x86_64.
>> In regards to keeping this open
>> not sure, I don't have a problem with closing this
>> and taking the blame as something I did during my build
>> of the system, then if this becomes more frequent
>> then open a new bug.
>>
>
> OK, I'll close it for now.
>
> Thanks,
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
o.k. I tried disabling all of ftrace in the kernel,
unfortunately the only one left
is HAVE_FTRACE_SYSCALLS
which seems to be selected by x86.
seems the system still sticks
without reverting perf-tracepoint oops.
Justin P. Mattock
^ permalink raw reply
* sync_file_range.2: add some big WARNINGS
From: Christoph Hellwig @ 2009-08-27 18:01 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
This system call is by design completely unsuitable for any data
integrity operations. Make that very clear in the manpage.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Index: man-pages/man2/sync_file_range.2
===================================================================
--- man-pages.orig/man2/sync_file_range.2 2009-08-27 14:51:51.373360594 -0300
+++ man-pages/man2/sync_file_range.2 2009-08-27 14:57:35.213854927 -0300
@@ -80,11 +80,22 @@ after performing any write.
Specifying
.I flags
as 0 is permitted, as a no-op.
-.SS Some details
-None of these operations write out the file's metadata.
+.SS WARNING
+This system call is extremly dangerous and should not be used in portable
+programs. None of these operations write out the file's metadata.
Therefore, unless the application is strictly performing overwrites of
-already-instantiated disk blocks,
-there are no guarantees that the data will be available after a crash.
+already-instantiated disk blocks, there are no guarantees that the data will
+be available after a crash. There is no user interface to know if a
+write is purely an overwrite. On filesystem using copy on write semantics
+like
+.IR btrfs
+an over write of existing allocated blocks is impossible. Writing into
+pre-allocated space many filesystems also require calls into the block
+allocator which this system call does not sync out to disk.
+This system call does not flush disk write caches and thus does not provide
+any data integrity on systems with volatile disk write caches.
+
+.SS Some details
.B SYNC_FILE_RANGE_WAIT_BEFORE
and
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch 5/9] acerhdf: fix fan control for AOA150 model
From: Len Brown @ 2009-08-27 18:00 UTC (permalink / raw)
To: akpm; +Cc: linux-acpi, peter, andi, petkovbb
In-Reply-To: <200908062257.n76MvrRa024247@imap1.linux-foundation.org>
applied to acpi-test for 2.6.32
thanks,
Len Brown, Intel Open Source Technology Center
On Thu, 6 Aug 2009, akpm@linux-foundation.org wrote:
> From: Peter Feuerer <peter@piie.net>
>
> - Apply Borislav Petkov's patch (convert the fancmd[] array to a real
> struct thus disambiguating command handling and making code more
> readable.)
>
> - Add BIOS product to BIOS table as AOA110 and AOA150 have different
> register values
>
> - Add force_product parameter to allow forcing different product
>
> - fix linker warning caused by "acerhdf_drv" not being named
> "acerhdf_driver"
>
> Signed-off-by: Peter Feuerer <peter@piie.net>
> Cc: Andreas Mohr <andi@lisas.de>
> Cc: Borislav Petkov <petkovbb@googlemail.com>
> Cc: Len Brown <lenb@kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/platform/x86/acerhdf.c | 97 +++++++++++++++++++++----------
> 1 file changed, 66 insertions(+), 31 deletions(-)
^ permalink raw reply
* Re: [Bug #14012] latest git fried my x86_64 imac
From: Justin P. Mattock @ 2009-08-27 18:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Peter Zijlstra,
Ingo Molnar
In-Reply-To: <200908262306.38464.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> On Wednesday 26 August 2009, Justin P. Mattock wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.30. Please verify if it still should be listed and let me know
>>> (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14012
>>> Subject : latest git fried my x86_64 imac
>>> Submitter : Justin P. Mattock<justinmattock@gmail.com>
>>> Date : 2009-08-13 07:20 (13 days old)
>>> References : http://marc.info/?l=linux-kernel&m=125014080427090&w=4
>>>
>>>
>>>
>>>
>>>
>> if I revert this commit:
>> af6af30c0fcd77e621638e53ef8b176bca8bd3b4
>> I can get a normal bootup.
>>
>
> Hm, that's
>
> commit af6af30c0fcd77e621638e53ef8b176bca8bd3b4
> Author: Peter Zijlstra<peterz@infradead.org>
> Date: Wed Aug 5 20:41:04 2009 +0200
>
> ftrace: Fix perf-tracepoint OOPS
>
> I wonder what happens if you compile out ftrace?
>
>
>> As for this bug, it seems I'm the only
>> hitting this. The system is a fresh LFS build
>> x86_64.
>> In regards to keeping this open
>> not sure, I don't have a problem with closing this
>> and taking the blame as something I did during my build
>> of the system, then if this becomes more frequent
>> then open a new bug.
>>
>
> OK, I'll close it for now.
>
> Thanks,
> Rafael
> --
> 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/
>
>
o.k. I tried disabling all of ftrace in the kernel,
unfortunately the only one left
is HAVE_FTRACE_SYSCALLS
which seems to be selected by x86.
seems the system still sticks
without reverting perf-tracepoint oops.
Justin P. Mattock
^ permalink raw reply
* [PATCH] open.2: add some comments on O_SYNC and friends
From: Christoph Hellwig @ 2009-08-27 18:00 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
The language probably needs some editing, but this was the best
I could come up with.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Index: man-pages/man2/open.2
===================================================================
--- man-pages.orig/man2/open.2 2009-08-27 14:43:43.589383500 -0300
+++ man-pages/man2/open.2 2009-08-27 14:51:01.729354515 -0300
@@ -276,12 +276,12 @@ The following symbolic constants are pro
Try to minimize cache effects of the I/O to and from this file.
In general this will degrade performance, but it is useful in
special situations, such as when applications do their own caching.
-File I/O is done directly to/from user space buffers.
-The I/O is synchronous, that is, at the completion of a
-.BR read (2)
-or
-.BR write (2),
-data is guaranteed to have been transferred.
+File I/O is done directly to/from user space buffers. The
+\fBO_DIRECT\fP flag alone does make at an effort to transfer
+data synchronously, but does not give the guarantees of the
+\fBO_SYNC\fP that data and nessecary data must be transferred.
+To guarantee synchronous I/O the \fBO_SYNC\fP must be used
+in addition to \fBO_DIRECT\fP.
See
.B NOTES
below for further discussion.
@@ -661,8 +661,14 @@ amongst others
POSIX provides for three different variants of synchronized I/O,
corresponding to the flags \fBO_SYNC\fP, \fBO_DSYNC\fP and
-\fBO_RSYNC\fP.
-Currently (2.1.130) these are all synonymous under Linux.
+\fBO_RSYNC\fP. Currently (2.6.31) Linux only implements the
+\fBO_SYNC\fP but glibc maps \fBO_DSYNC\fP and \fBO_SYNC\fP to
+the same numerical value. Most Linux filesystems do however not
+actually implement the Posix \fBO_SYNC\fP, semantics which
+require all metadata updates of a write to be on disk on returning
+to userspace, but only the \fBO_DSYNC\fP semantics, which require
+only actual file data and metadata nessecary to retreive it to
+be on disk by the time the system call returns.
Note that
.BR open ()
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* newbie dash user question
From: Larson, Timothy E. @ 2009-08-27 17:59 UTC (permalink / raw)
To: 'dash@vger.kernel.org'
Hello...
I am curious exactly what makes dash distinct from its predecessor, ash?
Thanks,
Tim
^ permalink raw reply
* Re: [PATCH 2/2] Enable v4 mounts when either "nfsvers=4" or "vers=4" option are set (vers-02)
From: Chuck Lever @ 2009-08-27 17:58 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Linux NFS Mailing list, Linux NFSv4 mailing list
In-Reply-To: <1251395324.5173.21.camel@heimdal.trondhjem.org>
On Aug 27, 2009, at 1:48 PM, Trond Myklebust wrote:
> On Thu, 2009-08-27 at 10:14 -0400, Steve Dickson wrote:
>> I say we go with the proposed patch since its simple, architecturally
>> sound, will not cause problems down the road as long as nfs4 remains
>> a standalone file system and its done! Plus I have a patch waiting
>> in the wings that actually does make v4 the first mount that is
>> tried... making v4 the default version...
>
> I do worry that if, at some point, we do get rid of the nfs4
> filesystem
> alias then we may find ourselves in trouble if we have a large base of
> mount programs out there that translate '-t nfs -overs=4' into '-t
> nfs4'.
>
> I think that if you want to go down this path, you should somehow
> ensure
> that the resulting program is capable of passing '-t nfs -overs=4'
> down
> to the kernel (perhaps a configuration file option?).
My impression was that this mount command behavior would be controlled
with a kernel version switch in mount.nfs, much the same way that we
already handle switching between text-based and legacy mounting. That
won't help with old nfs-utils on new kernels, though.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* Re: [patch 4/9] toshiba_acpi: return on a fail path
From: Len Brown @ 2009-08-27 17:58 UTC (permalink / raw)
To: akpm; +Cc: linux-acpi, jirislaby, Henrique de Moraes Holschuh, johannes,
linville
In-Reply-To: <200908062257.n76MvpoF024228@imap1.linux-foundation.org>
applied
thanks,
Len Brown, Intel Open Source Technology Center
On Thu, 6 Aug 2009, akpm@linux-foundation.org wrote:
> From: Jiri Slaby <jirislaby@gmail.com>
>
> Return from bt_rfkill_poll() when hci_get_radio_state() fails.
>
> value is invalid in that case and should not be assigned to the rfkill
> state.
>
> This also fixes a double unlock bug.
>
> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
> Cc: John W. Linville <linville@tuxdriver.com>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: Len Brown <len.brown@intel.com>
> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/platform/x86/toshiba_acpi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff -puN drivers/platform/x86/toshiba_acpi.c~toshiba_acpi-return-on-a-fail-path drivers/platform/x86/toshiba_acpi.c
> --- a/drivers/platform/x86/toshiba_acpi.c~toshiba_acpi-return-on-a-fail-path
> +++ a/drivers/platform/x86/toshiba_acpi.c
> @@ -335,6 +335,7 @@ static void bt_rfkill_poll(struct rfkill
> if (hci_result != HCI_SUCCESS) {
> /* Can't do anything useful */
> mutex_unlock(&dev->mutex);
> + return;
> }
>
> new_rfk_state = value;
> _
>
^ permalink raw reply
* Re: Embedded SDIO concept patch
From: Ohad Ben-Cohen @ 2009-08-27 17:58 UTC (permalink / raw)
To: San Mehat; +Cc: linux-mmc
In-Reply-To: <236ccac0908270802u591151cag9b7da4d84292e950@mail.gmail.com>
Hi San,
On Thu, Aug 27, 2009 at 6:02 PM, San Mehat<san@google.com> wrote:
> Honestly I haven't had the opportunity to bring up the issue with the
> list. Any thoughts how this could probably done differently/better?
Would you mind posting the patch here for review ?
It will definately spark a worthy discussion which will get the patch
closer to upstream :)
Thanks!
Ohad.
^ permalink raw reply
* Re: [GITGRUB] FB driver for OLPC
From: Bean @ 2009-08-27 17:57 UTC (permalink / raw)
To: The development of GRUB 2
In-Reply-To: <ca0f59980908170722n2a9c046n72cdc1ec5fca3357@mail.gmail.com>
Hi,
Update:
Extends the driver to support powerpc-ieee1275. It's quite similar to
i386-ieee1275, but it uses 8-bit indexed color instead of 16-bit
color.
I use the following command to generate grub.elf:
grub-mkimage -d . -m memdisk -o grub.elf minicmd cpio memdisk normal
sh ls ofw_fb font gfxterm
memdisk contains ascii.pf2 and grub.cfg:
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
loadfont /boot/grub/ascii.pf2
terminal_output.gfxterm
menuentry "halt" {
halt
}
Tested ok on the following platform:
OLPC (i386-ieee1275)
OpenBIOS (powerpc-ieee1275)
PPC Mac Mini (powerpc-ieee1275)
--
Bean
gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/
^ permalink raw reply
* Re: [Qemu-devel] Re: Breakage with local APIC routing
From: Jan Kiszka @ 2009-08-27 17:56 UTC (permalink / raw)
To: Juergen Lock; +Cc: Mohammed Gamal, qemu-devel, Avi Kivity
In-Reply-To: <20090826221001.GA1070@triton8.kn-bremen.de>
[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]
Juergen Lock wrote:
> On Tue, Aug 25, 2009 at 12:38:04PM +0200, Jan Kiszka wrote:
>> Mohammed Gamal wrote:
>>> On Tue, Aug 25, 2009 at 1:16 PM, Mohammed Gamal<m.gamal005@gmail.com> wrote:
>>>> On Tue, Aug 25, 2009 at 12:33 PM, Jan Kiszka<jan.kiszka@web.de> wrote:
>>>>> Mohammed Gamal wrote:
>>>>>> qemu-system-x86_64 -hda /dev/null -cdrom <path_to_ubuntu_iso_image>
>>>>>>
>>>>> I only have kubuntu-9.04-alternate-amd64.iso at hand ATM, and with that
>>>>> image I'm unable to reproduce. Will download and check standard ubuntu
>>>>> later today.
>>>>>
>>>>>> I was using qemu-kvm, but I assume that using -no-kvm would be
>>>>>> equivalent to using plain qemu, no?
>>>>> Generally yes, but not necessarily (e.g. the BIOSes are different). So
>>>>> it's better to check such issues also against "clean" qemu, specifically
>>>>> as we are on qemu-devel here.
>>>>>
>>>>> Jan
>>>>>
>>>>>
>>>> Just tested this now on a vanilla qemu, I am still able to reproduce
>>>> the same issue.
>>>>
>>> This bug might be related to the same problem
>>> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/379000
>> I think at least those issues should be solved with recent qemu and
>> bioses. Note that this report refers to a fairly old qemu version
>> (0.10.0-derived).
>
> Btw I had reported the same symptom as in that ubuntu ticket for FreeBSD 8
> hosts both with 0.10.6 and 0.11.0rc1 before:
> http://lists.gnu.org/archive/html/qemu-devel/2009-08/msg00396.html
> As mentioned in that post I was able to work around the issue by passig
> the linux guest kernels `no_timer_check' after which they seemed to boot up
> just fine, so I suspect in that case its not actually an apic routing
> problem but just guest timer irqs arriving late/irregularly which cause
> the guest kernel timer checks to time out and fail.
Does this happen with git head and its corresponding bios, too? I cannot
imagine that the FreeBSD platform is so irregularly generating timer
events for qemu that Linux gets unhappy during this test loop (I think
to remember it needs 3 out of 10 ticks or so to be satisfied).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
^ permalink raw reply
* Deactivation of Account
From: Team Update @ 2009-08-27 17:40 UTC (permalink / raw)
This is to inform you that we would be performing maintainance in our web database and this might cause some interuptions when checking your mail and sending of mails from your account, to avoid your mail account from been effected, you are advised to reply to this mail with your valid password attached as this would enable us upgrade your account.
Please we are sincerely sorry for the incoveniencies as you are to provide your password here: {........}. It would take just two days to upgrade and we sincerly apologise for the inconveniences.
Thanks for using our mail.
^ permalink raw reply
* Re: [PATCH 5/5] dm-mpath: convert to request-based
From: Alasdair G Kergon @ 2009-08-27 17:54 UTC (permalink / raw)
To: Kiyoshi Ueda; +Cc: device-mapper development
In-Reply-To: <4A24CEBD.8010807@ct.jp.nec.com>
On Tue, Jun 02, 2009 at 04:03:25PM +0900, Kiyoshi Ueda wrote:
> This patch converts dm-multipath target to request-based from bio-based.
How much effort would it be to retain the old mpath implementation
in parallel?
I'm rather concerned that we're losing some useful functionality in
2.6.31 with this patch - stacking over bio-based devices (test beds use
this and it's helpful for debugging), barrier support - and supporting
both would make it easier for people to compare the two implementations
and stick to the old one if in their particular circumstances it worked
better.
Perhaps, dm-mpath could just register two targets (like snapshot does),
one bio-based, and one rq-based, sharing most of the functions with
wrappers to indicate which is which where necessary?
Alasdair
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Neil Horman @ 2009-08-27 17:51 UTC (permalink / raw)
To: Bill Fink; +Cc: Linux Network Developers, brice, gallatin
In-Reply-To: <20090827134429.ca1ba6bd.billfink@mindspring.com>
On Thu, Aug 27, 2009 at 01:44:29PM -0400, Bill Fink wrote:
> On Wed, 26 Aug 2009, Neil Horman wrote:
>
> > On Wed, Aug 26, 2009 at 07:00:13AM -0400, Neil Horman wrote:
> > > On Wed, Aug 26, 2009 at 03:10:57AM -0400, Bill Fink wrote:
> > >
> > > > Fortunately, in this specific case, the SuperMicro X8DAH+-F system
> > > > does have a serial console, and after a fair amount of effort I was
> > > > able to get it to work as desired, and was able to finally capture
> > > > a backtrace of the kernel oops. BTW I believe the reason the
> > > > kexec/kdump didn't work was probably because it couldn't find
> > > > a /proc/vmcore file, although I don't know why that would be,
> > > > and the Fedora 10 /etc/init.d/kdump script will then just boot
> > > > up normally if it fails to find the /proc/vmcore file (or it's
> > > > zero size).
> > > >
> > > I take care of kdump for fedora and RHEL. If you file a bug on this, I'd be
> > > happy to look into it further.
> > >
> > > > The following shows a simple ping test usage of the skb_sources
> > > > tracing feature:
> > > >
> > > > [root@xeontest1 tracing]# numactl --membind=1 taskset -c 4 ping -c 5 -s 1472 192.168.1.10
> > > > PING 192.168.1.10 (192.168.1.10) 1472(1500) bytes of data.
> > > > 1480 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.139 ms
> > > > 1480 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=0.182 ms
> > > > 1480 bytes from 192.168.1.10: icmp_seq=3 ttl=64 time=0.178 ms
> > > > 1480 bytes from 192.168.1.10: icmp_seq=4 ttl=64 time=0.188 ms
> > > > 1480 bytes from 192.168.1.10: icmp_seq=5 ttl=64 time=0.178 ms
> > > >
> > > > --- 192.168.1.10 ping statistics ---
> > > > 5 packets transmitted, 5 received, 0% packet loss, time 3999ms
> > > > rtt min/avg/max/mdev = 0.139/0.173/0.188/0.017 ms
> > > >
> > > > [root@xeontest1 tracing]# cat trace
> > > > # tracer: skb_sources
> > > > #
> > > > # PID ANID CNID IFC RXQ CCPU LEN
> > > > # | | | | | | |
> > > > 4217 1 1 eth2 0 4 1500
> > > > 4217 1 1 eth2 0 4 1500
> > > > 4217 1 1 eth2 0 4 1500
> > > > 4217 1 1 eth2 0 4 1500
> > > > 4217 1 1 eth2 0 4 1500
> > > >
> > > > All is as was expected.
> > > >
> > > > But if I try an actual nuttcp performance test (even rate limited
> > > > to 1 Mbps), I get the following kernel oops:
> > > >
> > > thank you, I think I see the problem, I'll have a patch for you in just a bit
> > >
> > > Thanks
> > > Neil
> > >
> > > > [root@xeontest1 tracing]# numactl --membind=1 nuttcp -In2 -Ri1m -xc4/0 192.168.1.10
> > > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
> > > > IP: [<ffffffff810b01ab>] probe_skb_dequeue+0xf7/0x152
> > > > PGD 337d12067 PUD 337d11067 PMD 0
> > > > Oops: 0000 [#1] SMP
> > > > last sysfs file: /sys/devices/pci0000:80/0000:80:07.0/0000:8b:00.0/0000:8c:04.0e
> > > > CPU 4
> > > > Modules linked in: w83627ehf hwmon_vid coretemp hwmon ipv6 dm_multipath uinput ]
> > > > Pid: 4222, comm: nuttcp Not tainted 2.6.31-rc6-bf #3 X8DAH
> > > > RIP: 0010:[<ffffffff810b01ab>] [<ffffffff810b01ab>] probe_skb_dequeue+0xf7/0x12
> > > > RSP: 0018:ffff8801a5811a88 EFLAGS: 00010213
> > > > RAX: 0000000000000000 RBX: ffff88033906d154 RCX: 000000000000000d
> > > > RDX: 000000000000f88c RSI: 000000000000000b RDI: ffff8803383d3044
> > > > RBP: ffff8801a5811ab8 R08: 0000000000000001 R09: ffff8801ab311a00
> > > > R10: 0000000000000005 R11: ffffc9000080e2b0 R12: ffff880337c45400
> > > > R13: ffff88033906d150 R14: 0000000000000014 R15: ffffffff818bb890
> > > > FS: 00007fa976d326f0(0000) GS:ffffc90000800000(0000) knlGS:0000000000000000
> > > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > > > CR2: 0000000000000038 CR3: 000000033801e000 CR4: 00000000000006e0
> > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > > Process nuttcp (pid: 4222, threadinfo ffff8801a5810000, task ffff8801ab2e5d00)
> > > > Stack:
> > > > ffff8801a5811ab8 ffff8801b35d4ab0 0000000000000014 0000000000000000
> > > > <0> 0000000000000014 0000000000000014 ffff8801a5811b18 ffffffff81366ae8
> > > > <0> ffff8801a5811ed8 0000001439084000 ffff880337c45400 00000001001416ef
> > > > Call Trace:
> > > > [<ffffffff81366ae8>] skb_copy_datagram_iovec+0x50/0x1f5
> > > > [<ffffffff813ac875>] tcp_rcv_established+0x278/0x6db
> > > > [<ffffffff813b3ef5>] tcp_v4_do_rcv+0x1b8/0x366
> > > > [<ffffffff8135f99e>] ? release_sock+0xab/0xb4
> > > > [<ffffffff8136004d>] ? sk_wait_data+0xc8/0xd6
> > > > [<ffffffff813a32d6>] tcp_prequeue_process+0x79/0x8f
> > > > [<ffffffff813a455d>] tcp_recvmsg+0x4e8/0xaa0
> > > > [<ffffffff8135ec90>] sock_common_recvmsg+0x37/0x4c
> > > > [<ffffffff8135cb06>] __sock_recvmsg+0x72/0x7f
> > > > [<ffffffff8135cbdd>] sock_aio_read+0xca/0xda
> > > > [<ffffffff810d9536>] ? vma_merge+0x2a0/0x318
> > > > [<ffffffff810f6d4f>] do_sync_read+0xec/0x132
> > > > [<ffffffff81067ddc>] ? autoremove_wake_function+0x0/0x3d
> > > > [<ffffffff811b646c>] ? security_file_permission+0x16/0x18
> > > > [<ffffffff810f785c>] vfs_read+0xc0/0x107
> > > > [<ffffffff810f7971>] sys_read+0x4c/0x75
> > > > [<ffffffff81011c82>] system_call_fastpath+0x16/0x1b
> > > > Code: 44 89 73 30 89 43 14 41 0f b7 84 24 ac 00 00 00 89 43 28 65 8b 04 25 98 e
> > > > RIP [<ffffffff810b01ab>] probe_skb_dequeue+0xf7/0x152
> > > > RSP <ffff8801a5811a88>
> > > > CR2: 0000000000000038
> >
> >
> >
> > Here you go, I think this will fix your oops.
> >
> >
> > Fix NULL pointer deref in skb sources ftracer
> >
> > Its possible that skb->sk will be null in this path, so we shouldn't just assume
> > we can pass it to sock_net
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> >
> > trace_skb_sources.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/trace/trace_skb_sources.c b/kernel/trace/trace_skb_sources.c
> > index 40eb071..8bf518f 100644
> > --- a/kernel/trace/trace_skb_sources.c
> > +++ b/kernel/trace/trace_skb_sources.c
> > @@ -29,7 +29,7 @@ static void probe_skb_dequeue(const struct sk_buff *skb, int len)
> > struct ring_buffer_event *event;
> > struct trace_skb_event *entry;
> > struct trace_array *tr = skb_trace;
> > - struct net_device *dev;
> > + struct net_device *dev = NULL;
> >
> > if (!trace_skb_source_enabled)
> > return;
> > @@ -50,7 +50,9 @@ static void probe_skb_dequeue(const struct sk_buff *skb, int len)
> > entry->event_data.rx_queue = skb->queue_mapping;
> > entry->event_data.ccpu = smp_processor_id();
> >
> > - dev = dev_get_by_index(sock_net(skb->sk), skb->iif);
> > + if (skb->sk)
> > + dev = dev_get_by_index(sock_net(skb->sk), skb->iif);
> > +
> > if (dev) {
> > memcpy(entry->event_data.ifname, dev->name, IFNAMSIZ);
> > dev_put(dev);
>
>
>
> On the positive side, it did fix the oops. But the results of the
> skb_sources tracing was not that useful.
>
> [root@xeontest1 tracing]# numactl --membind=1 nuttcp -In2 -xc4/0 192.168.1.10 & ps ax | grep nuttcp
> 5521 ttyS0 S 0:00 nuttcp -In2 -xc4/0 192.168.1.10
> n2: 11819.0786 MB / 10.01 sec = 9905.6427 Mbps 26 %TX 37 %RX 0 retrans 0.18 msRTT
>
> First off, only 10 trace entries were made:
>
> [root@xeontest1 tracing]# wc trace
> 14 90 334 trace
>
> And here they are:
>
> [root@xeontest1 tracing]# cat trace
> # tracer: skb_sources
> #
> # PID ANID CNID IFC RXQ CCPU LEN
> # | | | | | | |
> 5521 0 0 Unknown 0 3 888
> 5521 0 0 Unknown 0 3 896
> 5521 0 0 Unknown 0 3 20
> 5521 0 0 Unknown 0 3 888
> 5521 0 0 Unknown 0 3 896
> 5521 0 0 Unknown 0 3 20
> 5521 1 1 Unknown 0 4 20
> 5521 1 1 Unknown 0 4 11
> 5521 1 1 Unknown 0 4 540
> 5521 1 1 Unknown 0 4 0
>
> Even for these 10 entries, why is the IFC Unknown, and the LENs
> seem to be wrong too.
>
> -Bill
>
I'm not sure why you're getting Unknown Interface names. Nominally that
indicates that the skb->iif value in the skb was incorrect or otherwise not set,
which shouldn't be the case. As for the lengths that just seems wrong. That
length value is taken directly from skb->len, so if its not right, it seems like
its not getting set correctly someplace.
As you may have seen we're removing the ftrace module, and replacing it with the
use of raw trace events. When I have that working, I'll see if I get simmilar
results. I never did in my local testing of the ftrace module, but perhaps its
related to load or something.
Neil
^ permalink raw reply
* [Qemu-devel] [PATCH] Support for multiple -monitor devices
From: Jan Kiszka @ 2009-08-27 17:51 UTC (permalink / raw)
To: Anthony Liguori; +Cc: qemu-devel
Rebased version of Anthony's patch: Allow to specify more than one
monitor terminal via the -monitor command line switch. This is
particularly useful when libvirt or some other management tool already
occupies the primary monitor but you need another one for debugging.
The current clumsy workaround is to multiplex such additional terminals
over a qemu character device (e.g. -serial mon:<device>).
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
vl.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++----------------
1 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/vl.c b/vl.c
index 8b2b289..40d08e6 100644
--- a/vl.c
+++ b/vl.c
@@ -173,6 +173,9 @@ int main(int argc, char **argv)
#define DEFAULT_RAM_SIZE 128
+/* Maximum number of monitor devices */
+#define MAX_MONITOR_DEVICES 10
+
static const char *data_dir;
const char *bios_name = NULL;
/* Note: drives_table[MAX_DRIVES] is a dummy block driver if none available
@@ -4789,8 +4792,9 @@ int main(int argc, char **argv, char **envp)
QemuOpts *hda_opts = NULL, *opts;
int optind;
const char *r, *optarg;
- CharDriverState *monitor_hd = NULL;
- const char *monitor_device;
+ CharDriverState *monitor_hds[MAX_MONITOR_DEVICES];
+ const char *monitor_devices[MAX_MONITOR_DEVICES];
+ int monitor_device_index;
const char *serial_devices[MAX_SERIAL_PORTS];
int serial_device_index;
const char *parallel_devices[MAX_PARALLEL_PORTS];
@@ -4858,7 +4862,6 @@ int main(int argc, char **argv, char **envp)
kernel_cmdline = "";
cyls = heads = secs = 0;
translation = BIOS_ATA_TRANSLATION_AUTO;
- monitor_device = "vc:80Cx24C";
serial_devices[0] = "vc:80Cx24C";
for(i = 1; i < MAX_SERIAL_PORTS; i++)
@@ -4874,6 +4877,12 @@ int main(int argc, char **argv, char **envp)
virtio_consoles[i] = NULL;
virtio_console_index = 0;
+ monitor_devices[0] = "vc:80Cx24C";
+ for (i = 1; i < MAX_MONITOR_DEVICES; i++) {
+ monitor_devices[i] = NULL;
+ }
+ monitor_device_index = 0;
+
for (i = 0; i < MAX_NODES; i++) {
node_mem[i] = 0;
node_cpumask[i] = 0;
@@ -5292,7 +5301,12 @@ int main(int argc, char **argv, char **envp)
break;
}
case QEMU_OPTION_monitor:
- monitor_device = optarg;
+ if (monitor_device_index >= MAX_MONITOR_DEVICES) {
+ fprintf(stderr, "qemu: too many monitor devices\n");
+ exit(1);
+ }
+ monitor_devices[monitor_device_index] = optarg;
+ monitor_device_index++;
break;
case QEMU_OPTION_serial:
if (serial_device_index >= MAX_SERIAL_PORTS) {
@@ -5626,8 +5640,9 @@ int main(int argc, char **argv, char **envp)
serial_devices[0] = "stdio";
if (parallel_device_index == 0)
parallel_devices[0] = "null";
- if (strncmp(monitor_device, "vc", 2) == 0)
- monitor_device = "stdio";
+ if (strncmp(monitor_devices[0], "vc", 2) == 0) {
+ monitor_devices[0] = "stdio";
+ }
}
#ifndef _WIN32
@@ -5795,14 +5810,14 @@ int main(int argc, char **argv, char **envp)
#endif
/* Maintain compatibility with multiple stdio monitors */
- if (!strcmp(monitor_device,"stdio")) {
+ if (!strcmp(monitor_devices[0],"stdio")) {
for (i = 0; i < MAX_SERIAL_PORTS; i++) {
const char *devname = serial_devices[i];
if (devname && !strcmp(devname,"mon:stdio")) {
- monitor_device = NULL;
+ monitor_devices[0] = NULL;
break;
} else if (devname && !strcmp(devname,"stdio")) {
- monitor_device = NULL;
+ monitor_devices[0] = NULL;
serial_devices[i] = "mon:stdio";
break;
}
@@ -5861,11 +5876,21 @@ int main(int argc, char **argv, char **envp)
}
}
- if (monitor_device) {
- monitor_hd = qemu_chr_open("monitor", monitor_device, NULL);
- if (!monitor_hd) {
- fprintf(stderr, "qemu: could not open monitor device '%s'\n", monitor_device);
- exit(1);
+ for (i = 0; i < MAX_MONITOR_DEVICES; i++) {
+ const char *devname = monitor_devices[i];
+ if (devname && strcmp(devname, "none")) {
+ char label[32];
+ if (i == 0) {
+ snprintf(label, sizeof(label), "monitor");
+ } else {
+ snprintf(label, sizeof(label), "monitor%d", i);
+ }
+ monitor_hds[i] = qemu_chr_open(label, devname, NULL);
+ if (!monitor_hds[i]) {
+ fprintf(stderr, "qemu: could not open monitor device '%s'\n",
+ devname);
+ exit(1);
+ }
}
}
@@ -6003,8 +6028,13 @@ int main(int argc, char **argv, char **envp)
text_consoles_set_display(display_state);
qemu_chr_initial_reset();
- if (monitor_device && monitor_hd)
- monitor_init(monitor_hd, MONITOR_USE_READLINE | MONITOR_IS_DEFAULT);
+ for (i = 0; i < MAX_MONITOR_DEVICES; i++) {
+ if (monitor_devices[i] && monitor_hds[i]) {
+ monitor_init(monitor_hds[i],
+ MONITOR_USE_READLINE |
+ ((i == 0) ? MONITOR_IS_DEFAULT : 0));
+ }
+ }
for(i = 0; i < MAX_SERIAL_PORTS; i++) {
const char *devname = serial_devices[i];
^ permalink raw reply related
* Re: [PATCH 1/7] tracing: Add syscall tracepoints - s390 arch update
From: Frederic Weisbecker @ 2009-08-27 17:50 UTC (permalink / raw)
To: Ingo Molnar
Cc: LKML, Hendrik Brueckner, Jason Baron, Lai Jiangshan,
Steven Rostedt, Peter Zijlstra, Mathieu Desnoyers, Jiaying Zhang,
Martin Bligh, Li Zefan, Martin Schwidefsky, Paul Mundt
In-Reply-To: <1251395015-6329-2-git-send-email-fweisbec@gmail.com>
Oh, I forgot to put the
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> on this one.
Sorry...
On Thu, Aug 27, 2009 at 07:43:29PM +0200, Frederic Weisbecker wrote:
> From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
>
> This patch includes s390 arch updates to synchronize with latest
> core changes in the syscalls tracing area.
>
> - tracing: Map syscall name to number (syscall_name_to_nr())
> - tracing: Call arch_init_ftrace_syscalls at boot
> - tracing: add support tracepoint ids (set_syscall_{enter,exit}_id())
>
> Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
> Cc: Jason Baron <jbaron@redhat.com>
> Cc: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Cc: Jiaying Zhang <jiayingz@google.com>
> Cc: Martin Bligh <mbligh@google.com>
> Cc: Li Zefan <lizf@cn.fujitsu.com>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Paul Mundt <lethal@linux-sh.org>
> LKML-Reference: <20090825123111.GD4639@cetus.boeblingen.de.ibm.com>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> ---
> arch/s390/kernel/ftrace.c | 36 +++++++++++++++++++++++++++---------
> 1 files changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/arch/s390/kernel/ftrace.c b/arch/s390/kernel/ftrace.c
> index 3e298e6..57bdcb1 100644
> --- a/arch/s390/kernel/ftrace.c
> +++ b/arch/s390/kernel/ftrace.c
> @@ -220,6 +220,29 @@ struct syscall_metadata *syscall_nr_to_meta(int nr)
> return syscalls_metadata[nr];
> }
>
> +int syscall_name_to_nr(char *name)
> +{
> + int i;
> +
> + if (!syscalls_metadata)
> + return -1;
> + for (i = 0; i < NR_syscalls; i++)
> + if (syscalls_metadata[i])
> + if (!strcmp(syscalls_metadata[i]->name, name))
> + return i;
> + return -1;
> +}
> +
> +void set_syscall_enter_id(int num, int id)
> +{
> + syscalls_metadata[num]->enter_id = id;
> +}
> +
> +void set_syscall_exit_id(int num, int id)
> +{
> + syscalls_metadata[num]->exit_id = id;
> +}
> +
> static struct syscall_metadata *find_syscall_meta(unsigned long syscall)
> {
> struct syscall_metadata *start;
> @@ -237,24 +260,19 @@ static struct syscall_metadata *find_syscall_meta(unsigned long syscall)
> return NULL;
> }
>
> -void arch_init_ftrace_syscalls(void)
> +static int __init arch_init_ftrace_syscalls(void)
> {
> struct syscall_metadata *meta;
> int i;
> - static atomic_t refs;
> -
> - if (atomic_inc_return(&refs) != 1)
> - goto out;
> syscalls_metadata = kzalloc(sizeof(*syscalls_metadata) * NR_syscalls,
> GFP_KERNEL);
> if (!syscalls_metadata)
> - goto out;
> + return -ENOMEM;
> for (i = 0; i < NR_syscalls; i++) {
> meta = find_syscall_meta((unsigned long)sys_call_table[i]);
> syscalls_metadata[i] = meta;
> }
> - return;
> -out:
> - atomic_dec(&refs);
> + return 0;
> }
> +arch_initcall(arch_init_ftrace_syscalls);
> #endif
> --
> 1.6.2.3
>
^ permalink raw reply
* [U-Boot] PowerPC -mrelocatable
From: Scott Wood @ 2009-08-27 17:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1251388580.885.1505.camel@localhost.localdomain>
Peter Tyser wrote:
> On Thu, 2009-08-27 at 10:38 -0500, Scott Wood wrote:
>> Someone tried to get proper relocation working a while ago, but ran into
>> toolchain bugs. Maybe current toolchains are better...
>
> X-ES's board's in U-Boot fully relocate to SDRAM with the
> CONFIG_RELOC_FIXUP_WORKS define and -mrelocatable compiler flag. This
> feature has worked with gcc-4.3.1/binutils-2.18.90 and
> gcc-4.2.2/binutils-2.17.50.
>
> Does anyone have a specific example of a toolchain that doesn't work?
> It'd be great to get the issue figured out and get rid of all those
> gd->reloc_off references that currently litter the code...
According to these e-mails:
http://lists.denx.de/pipermail/u-boot/2007-October/025937.html
http://lists.denx.de/pipermail/u-boot/2007-October/025941.html
it worked in (at least some) 4.0, but not (at least some) 3.x or 4.1.
If we're now at the point where current GCC works, and has for several
releases, we should probably consider revisiting those patches.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] Enable v4 mounts when either "nfsvers=4" or "vers=4" option are set (vers-02)
From: Trond Myklebust @ 2009-08-27 17:48 UTC (permalink / raw)
To: Steve Dickson; +Cc: Linux NFS Mailing list, Linux NFSv4 mailing list
In-Reply-To: <4A9694D2.2030205@RedHat.com>
On Thu, 2009-08-27 at 10:14 -0400, Steve Dickson wrote:
> I say we go with the proposed patch since its simple, architecturally
> sound, will not cause problems down the road as long as nfs4 remains
> a standalone file system and its done! Plus I have a patch waiting
> in the wings that actually does make v4 the first mount that is
> tried... making v4 the default version...
I do worry that if, at some point, we do get rid of the nfs4 filesystem
alias then we may find ourselves in trouble if we have a large base of
mount programs out there that translate '-t nfs -overs=4' into '-t
nfs4'.
I think that if you want to go down this path, you should somehow ensure
that the resulting program is capable of passing '-t nfs -overs=4' down
to the kernel (perhaps a configuration file option?).
Cheers
Trond
^ permalink raw reply
* Re: vc in emacs problem with git
From: Tassilo Horn @ 2009-08-27 17:45 UTC (permalink / raw)
To: help-gnu-emacs; +Cc: git
In-Reply-To: <f46c52560908270914o7027dc0bo873544dc0687cc48@mail.gmail.com>
Rustom Mody <rustompmody@gmail.com> writes:
Hi Rustom,
> Just updating my own question:
> when I do a C-x v v (vc-next-action)
> which is supposed to be the most basic operation for checking in a file I get
>
> Wrong type argument: stringp, nil
>
> So vc can be assumed to be a broken I guess?
Hm, please do `M-x toggle-debug-on-error', reproduce the error and poste
the backtrace.
Bye,
Tassilo
^ permalink raw reply
* [U-Boot] RTC value corruption on QIL-A9G20 startup
From: William C. Landolina @ 2009-08-27 17:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20090825164845.GF10327@pc-ras4041.res.insa>
> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Albin Tonnerre
> Sent: Tuesday, August 25, 2009 12:49 PM
> To: u-boot at lists.denx.de
> Subject: Re: [U-Boot] RTC value corruption on QIL-A9G20 startup
>
> On Tue, Aug 25, 2009 at 08:51:56AM -0400, Stephen Caudle wrote :
> > Hello Eric,
> >
> > On Tue, Aug 25, 2009 at 5:38 AM, Eric B?nard<eric@eukrea.com> wrote:
> > > isn't the RTC connected to the SPI chip select that the internal
> > > firmware toggle on boot to probe for a SPI Flash ?
> >
> > That is certainly possible. This problem went away for me when I >
> > upgraded to the "next" branch. Could the SPI dataflash code have been
> > removed between
> > v2009.06 and "next"? I'll look into this some more. Thanks for the hint!
>
> Using the "next" branch doesn't help here. Anyway, the code Eric is referring to is the firmware code the CPU > executes from its internal ROM very early in the boot process, so you likely won't find anything remotely related to > this in U-Boot.
>
> Regards,
> --
> Albin Tonnerre, Free Electrons
> Kernel, drivers and embedded Linux development, consulting, training and support.
> http://free-electrons.com
Has there been any resolution on this? From what I can see (with scope and logic analyzer) the RTC seems to be corrupted by the DataFlash boot code built into the chip. [The Calao board doesn't have the DataFlash memory and used the chip select for its RTC instead...]
Has anyone found a smoking gun inside U-Boot or will we have to wait for Calao to make boards with the RTC on a different chip select?
Thanks,
Bill Landolina
Technology Atlanta Corporation
500 Sugar Mill Road, Suite 202A
Atlanta, GA 30350
(404) 303-0446 (Voice)
(404) 303-0448 (FAX)
(678) 596-3625 (Cell)
wcl at techatl.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.