* [U-Boot] [PATCH 02/39] GCC4.6: Squash warnings in common/usb.c
From: Stefano Babic @ 2011-10-24 12:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-3-git-send-email-marek.vasut@gmail.com>
On 10/22/2011 02:16 AM, Marek Vasut wrote:
> usb.c: In function ?usb_parse_config?:
> usb.c:331:17: warning: variable ?ch? set but not used
> [-Wunused-but-set-variable]
> usb.c: In function ?usb_hub_port_connect_change?:
> usb.c:1123:29: warning: variable ?portchange? set but not used
> [-Wunused-but-set-variable]
> usb.c: In function ?usb_hub_configure?:
> usb.c:1183:25: warning: variable ?hubsts? set but not used
> [-Wunused-but-set-variable]
>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Mike Frysinger <vapier@gentoo.org>
> ---
> common/usb.c | 21 +++++++--------------
> 1 files changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/common/usb.c b/common/usb.c
> index 2cd50db..bed5116 100644
> --- a/common/usb.c
> +++ b/common/usb.c
> @@ -56,16 +56,16 @@
> #endif
>
> #ifdef DEBUG
> -#define USB_DEBUG
> -#define USB_HUB_DEBUG
> -#endif
> -
> -#ifdef USB_DEBUG
> -#define USB_PRINTF(fmt, args...) printf(fmt , ##args)
> +#define USB_DEBUG 1
> +#define USB_HUB_DEBUG 1
Why do you nedd to set a value when then later to check only with #ifdef
if it is defined or not ?
> #else
> -#define USB_PRINTF(fmt, args...)
> +#define USB_DEBUG 0
> +#define USB_HUB_DEBUG 0
Maybe #undef ?
Best regards,
Stefano babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH] sparse, llvm: Fix 'void *' pointer code generation
From: Jonathan Neuschäfer @ 2011-10-24 12:14 UTC (permalink / raw)
To: Pekka Enberg
Cc: Linus Torvalds, Pekka Enberg, linux-sparse, Christopher Li,
Jeff Garzik
In-Reply-To: <alpine.LFD.2.02.1110241455580.13879@tux.localdomain>
On Mon, Oct 24, 2011 at 02:56:41PM +0300, Pekka Enberg wrote:
> Fix the issue by switching to LLVMIntType(bits_per_pointer) in
> sym_basetype_type().
You didn't update the commit message.
--
Jonathan Neuschäfer
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 43/49] spi: irq: Remove IRQF_DISABLED
From: Grant Likely @ 2011-10-24 12:14 UTC (permalink / raw)
To: Yong Zhang; +Cc: linux-kernel, tglx, spi-devel-general
In-Reply-To: <1319277421-9203-44-git-send-email-yong.zhang0@gmail.com>
On Sat, Oct 22, 2011 at 05:56:55PM +0800, Yong Zhang wrote:
> Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
> We run all interrupt handlers with interrupts disabled
> and we even check and yell when an interrupt handler
> returns with interrupts enabled (see commit [b738a50a:
> genirq: Warn when handler enables interrupts]).
>
> So now this flag is a NOOP and can be removed.
>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Applied, thanks.
g.
> ---
> drivers/spi/spi-bfin5xx.c | 2 +-
> drivers/spi/spi-coldfire-qspi.c | 2 +-
> drivers/spi/spi-ppc4xx.c | 2 +-
> drivers/spi/spi-sh-msiof.c | 2 +-
> drivers/spi/spi-sh.c | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/spi/spi-bfin5xx.c b/drivers/spi/spi-bfin5xx.c
> index b8d25f2..3b83ff8 100644
> --- a/drivers/spi/spi-bfin5xx.c
> +++ b/drivers/spi/spi-bfin5xx.c
> @@ -1098,7 +1098,7 @@ static int bfin_spi_setup(struct spi_device *spi)
>
> if (chip->pio_interrupt && !drv_data->irq_requested) {
> ret = request_irq(drv_data->spi_irq, bfin_spi_pio_irq_handler,
> - IRQF_DISABLED, "BFIN_SPI", drv_data);
> + 0, "BFIN_SPI", drv_data);
> if (ret) {
> dev_err(&spi->dev, "Unable to register spi IRQ\n");
> goto error;
> diff --git a/drivers/spi/spi-coldfire-qspi.c b/drivers/spi/spi-coldfire-qspi.c
> index ae2cd1c..7397c4d 100644
> --- a/drivers/spi/spi-coldfire-qspi.c
> +++ b/drivers/spi/spi-coldfire-qspi.c
> @@ -487,7 +487,7 @@ static int __devinit mcfqspi_probe(struct platform_device *pdev)
> goto fail2;
> }
>
> - status = request_irq(mcfqspi->irq, mcfqspi_irq_handler, IRQF_DISABLED,
> + status = request_irq(mcfqspi->irq, mcfqspi_irq_handler, 0,
> pdev->name, mcfqspi);
> if (status) {
> dev_dbg(&pdev->dev, "request_irq failed\n");
> diff --git a/drivers/spi/spi-ppc4xx.c b/drivers/spi/spi-ppc4xx.c
> index b267fd9..8ec43e0 100644
> --- a/drivers/spi/spi-ppc4xx.c
> +++ b/drivers/spi/spi-ppc4xx.c
> @@ -514,7 +514,7 @@ static int __init spi_ppc4xx_of_probe(struct platform_device *op)
> /* Request IRQ */
> hw->irqnum = irq_of_parse_and_map(np, 0);
> ret = request_irq(hw->irqnum, spi_ppc4xx_int,
> - IRQF_DISABLED, "spi_ppc4xx_of", (void *)hw);
> + 0, "spi_ppc4xx_of", (void *)hw);
> if (ret) {
> dev_err(dev, "unable to allocate interrupt\n");
> goto free_gpios;
> diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
> index 2f61a84..51b14c9 100644
> --- a/drivers/spi/spi-sh-msiof.c
> +++ b/drivers/spi/spi-sh-msiof.c
> @@ -636,7 +636,7 @@ static int sh_msiof_spi_probe(struct platform_device *pdev)
> goto err2;
> }
>
> - ret = request_irq(i, sh_msiof_spi_irq, IRQF_DISABLED,
> + ret = request_irq(i, sh_msiof_spi_irq, 0,
> dev_name(&pdev->dev), p);
> if (ret) {
> dev_err(&pdev->dev, "unable to request irq\n");
> diff --git a/drivers/spi/spi-sh.c b/drivers/spi/spi-sh.c
> index 9eedd71..e0343d4 100644
> --- a/drivers/spi/spi-sh.c
> +++ b/drivers/spi/spi-sh.c
> @@ -484,7 +484,7 @@ static int __devinit spi_sh_probe(struct platform_device *pdev)
> goto error2;
> }
>
> - ret = request_irq(irq, spi_sh_irq, IRQF_DISABLED, "spi_sh", ss);
> + ret = request_irq(irq, spi_sh_irq, 0, "spi_sh", ss);
> if (ret < 0) {
> dev_err(&pdev->dev, "request_irq error\n");
> goto error3;
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH] Add SoundCard driver for OKI SEMICONDUCTOR ML7213 IOH
From: Tomoya MORINAGA @ 2011-10-24 12:12 UTC (permalink / raw)
To: Takashi Iwai
Cc: perex, linux-kernel, Wang, Qi, Wang, Yong Y, Clark, Joel,
Ewe, Kok Howg, Liam Girdwood, Mark Brown, alsa-devel
In-Reply-To: <s5h7h3ysa4l.wl%tiwai@suse.de>
Hi Iwai,
(2011/10/21 23:16), Takashi Iwai wrote:
> At Mon, 17 Oct 2011 13:28:39 +0900,
> Tomoya MORINAGA wrote:
>>
>> Hi Iwai,
>>
>> We have just started porting to ASoC structure.
>
> Please add ASoC maintainers to Cc if you have questions about ASoC.
>
>> I have a question.
>>
>> As you reviewed before, currently, our driver consists of 2 parts,
>> Soundcard driver and I2S driver.
>>
>> Soundcard consists of 2 parts
>> - ALSA interface / control part
>> - CODEC control part
>>
>> I2S driver consists of 4 parts
>> - HAL
>> - DMA control / interrupt control
>> - Soundcard interface part
>> - PCI interface function
>>
>> According to "soc" Documentation,
>> We must divide to 3 parts, platform driver, machine driver and codec driver.
>>
>> So, I divided like the following parts.
>>
>> platform driver
>> - ALSA interface / control part
>> - HAL
>> - DMA control / interrupt control
>> - Soundcard interface part
>> - PCI interface function
>>
>> machine driver
>> - (none)
>>
>> codec driver
>> - CODEC control part
>>
>> Is the above dividing true ?
>
> Not really. ASoC is designed to be much more modular. Take a look at
> the codes in sound/soc/*. You'll grasp how the components are split.
> (The documents in Documentation/sound/alsa/soc/ are slightly
> obsoleted...)
Of course, I read Documentation/sound/alsa/soc/ and sound/soc/*.
However, it's not easy for me.
I have just 2 questions.
1. PCI interface function.
Any current ASoC drivers don't have PCI interface function.
So I don't know where the function should be in machine driver or
platform driver.
2. Register Access
Can platform driver access register ?
According to the soc document, platform driver must not access hardware,
however, some drivers looks accessing their hardware.
>
> The conversion of PCM part is usually straightforward, as found in
> *-pcm.c. The DAI setup depends on the hardware implementation.
> That's for machine driver. But it's hard to tell in more details
> until I see the actual code snippet you are working on...
I understand.
I'm going to send our modified driver soon.
Thanks,
--
tomoya
ROHM Co., Ltd.
^ permalink raw reply
* github tree cleanup
From: Jonathan Cameron @ 2011-10-24 12:12 UTC (permalink / raw)
To: linux-iio@vger.kernel.org
Hi All,
Just a quick heads up on state of the branches there.
https://github.com/jic23/linux-iio/branches
master - what has either gone to Greg, or what I intend to
send shortly.
outofstaging - current proposal for code in drivers/iio/
including the pull in kernel interfaces.
inkern-staging - experimental stuff for doing more complex
in kernel interfacing. Right now, demux code and a
pretty much direct copy to the staging tree of the in kernel
pull interfaces proposed for the outofstaging tree.
Note all three of these will be rebased a random times to
try and keep our history fairly clean whilst we are doing
so many different series at the same time.
I'll be posting updated versions of outofstaging shortly.
I don't really intend to post the patches lifted across
to the inkern-staging tree as they are exactly the same
up to a few renames.
Jonathan
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH] batman-adv: unify hash_entry field position in tt_local/global_entry
From: Marek Lindner @ 2011-10-24 12:12 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
In-Reply-To: <1319237739-7686-1-git-send-email-ordex@autistici.org>
On Saturday, October 22, 2011 00:55:39 Antonio Quartulli wrote:
> Function tt_response_fill_table() actually uses a tt_local_entry pointer to
> iterate either over the local or the global table entries (it depends on
> the what hash table is passed as argument). To iterate over such entries
> the hlist_for_each_entry_rcu() macro has to access their "hash_entry"
> field which MUST be at the same position in both the tt_global/local_entry
> structures.
Patch was applied in revision 474f917.
Thanks,
Marek
PS: Antonio, please keep in mind that I apply this patch as a temporary
measure not as the final fix.
^ permalink raw reply
* Re: Snapshot rollback
From: Fajar A. Nugraha @ 2011-10-24 12:11 UTC (permalink / raw)
To: linux-btrfs
In-Reply-To: <loom.20111024T101858-236@post.gmane.org>
On Mon, Oct 24, 2011 at 3:24 PM, dima <dolenin@parallels.com> wrote:
> Fajar A. Nugraha <list <at> fajar.net> writes:
>
>> A problem with that, though, if you decide to put /boot on btrfs as
>> well. Grub uses the default subvolume to determine paths (for kernel,
>> initrd, etc). A workaround is to manually create and manage your
>> grub.cfg (or create and use a manual-managed include file, like
>> custom-top.cfg, that gets parsed before the automatically created
>> entries).
>
> Oops, sorry, I was incorrect of course. Thanks Fajar.
> I do have /boot in my subvolid=0 because bootloaders can't read inside
> subvolumes (other than the default) as far as I understand.
> And I just bind /boot through fstab.
AFAIK you have three possible ways to use /boot on btrfs:
(1) put /boot on subvolid=0, don't change the default subvolume. That
works, but all your snapshot/subvols will be visible under /boot. Some
people might not want that for estetic reason.
(2) put /boot (or /, when /boot is part of / ) on a subvolume, then
change the default subvolume. This works cleanly, but there were some
problems in the past when changing the default subvolume (at least I
had problem). Current kernel version might not have this problem
anymore (I haven't tried again)
(3) put /boot on a subvolume, do not change the default subvolume, and
manage grub.cfg manually. This is what I currently do.
I wish grub's btrfs support is more like zfs support, where both the
bootloader and tools (e.g. update-grub, grub-probe, etc) can
intellegently recognize what dataset /boot is on, and create the
correct entry. For example, if you have this
# df -h /boot
Filesystem Size Used Avail Use% Mounted on
rpool/ROOT/ubuntu-1 384G 1.2G 383G 1% /
rpool/ROOT/ubuntu-1/boot
383G 71M 383G 1% /boot
... then grub.cfg will have an entry like this
zfs-bootfs ($root) bootfs
linux /ROOT/ubuntu-1/boot/@/vmlinuz-2.6.38-10-generic root=/dev/sda5
ro boot=zfs $bootfs rpool=rpool bootfs=rpool/ROOT/ubuntu-1
initrd /ROOT/ubuntu-1/boot/@/initrd.img-2.6.38-10-generic
This flexibility allows me (for example) to have multiple version of
kernel, initrd, and root fs in different datasets, all selectable
during boot process (possibly by manually editing grub command line to
suplly the correct path/argument). Good for rescue purposes, just in
case a recent update made the system broken :)
The closest thing we can get to that with btrfs is currently option
(1), as option (2) requires you to boot to an alternate environment
(e.g live cd) to change the default subvol first.
--
Fajar
^ permalink raw reply
* Re: [dm-crypt] [RFC] dm-crypt and hardware-optimized crypto modules
From: Jonas Meurer @ 2011-10-24 12:11 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <20111024062115.GA5324@tansi.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 24.10.2011 08:21, schrieb Arno Wagner:
> Hi Jonas,
Hey Arno,
> the definite authority on this is Milan, but as far as I understand
> module autoloading, as long as an implementation for a requested
> cipher is already loaded, that will be used. Now, I expect it would
> be possible to not build the normal AES module and thereby have the
> HW-supported AES module loade automatically when needed. As the
> Debian distro-kernel cannot know HW-support would be there, it
> obviously defaults to the software implementation.
Nope, the Debian distro-kernel has software implementation built into
the kernel, and hardware-accelerated drivers built as modules. So
according to Milans answers, the kernel crypto engine should load and
use the hardware-optimised drivers in case they're supported.
> AFAIK, if both HW and SW support are loaded, HW support is used as
> default. I think there is some kind of priority system in place.
> But I am really only guessing here.
I guess you're correct here ;)
> I see two ways around this:
>
> 1. Load the HW module manually (or scripted). While I have not used
> a Debian Distro kernel for a long time, I think adding the
> HW-module to /etc/modules should accomplish that. Noneed to mess
> with the initrd, unless possibly if you have encrypted root.
>
> 2. Roll your own kernel, possibly with HW support statically
> compiled in. I have used Debian with kernels from kernel.org and
> module-support turned off with good success for about 10 years now.
> (I don't like initrds. Good for distros, but they complicate things
> and complexity is the enemy of reliablity and efficiency. Also, I
> like to mess around with my installatons and initrds make that
> harder. I also do not like to use kernel modules very much,
> although it is definitely good that they are there.)
>
> To use your own kernel with Debian, just boot it and tell it the
> root partition. Of course you have to make sure it somehow has the
> drivers it needs to fnd and mount the root partition.
As I'm the maintainer of cryptsetup in Debian, I'm searching for a
solution for default setups. I know how to manually tweak setups to
use the hardware-optimized crypto drivers. But I need a solution for
the default setup with default distro-kernel. Thus building custom
kernels is out of scope in my case.
Greetings,
jonas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOpVXxAAoJEFJi5/9JEEn+rAcP+gMbUNbx4/YkZzD2CEEUfJsr
QFgUth+B5znHs7YCo9ndR+uDNyiYu0/EQA9xvjvp/lz8ageynrCiawaClTfytIJW
lpA+qL89WX3gPtKIK/W8TKVor1ArWS6ZqzLZvO4avxt0bqTxfHRR7dilWgvtlWQt
AcA2VeiBwDp7JtTTyKSPgIFYaVDsWo/GhPShQ4fMMQOH0HeuyLOYUgcuP4TlKrPN
17U7AlfkMPwDc1asoMdyAev+0G+3NT8vY+0ppd+aiQygpEJgafJj+UrXjlEb8qBl
s8Byff44+FtyKVbG5q6njS6EWlTygwkVH2YJs5pSqNyJG+EALuj/Mwv8JAzefoYE
GoF1xImNJPLdWf5SfuWw8t+6pOEydtkSKIBAxvaNpTuB8T122iei+GI33RIkH8eR
q6cmdP9Kxau+Hsa6WEMB0fqjzNdekNdtzQHLKqEHjW9Fu4UekzKcV1bslU4hntvh
KA2UTCOxkmopLmWSty2dAfqgVALzSRLBJjC/V6bjWoY/vUCQDOFjexv2vIf4F4Zq
jISypLfsFytZQqOSTcd2gEBOOXEyua+D02Wq6H3SRzxqPRzxAPMFxAO1aVD/Y7lh
64cLd2bfEiDW+IgTUOQAAouOIVIWYRAsmFwEsmP+NDvLDf6b14cHs+Q2m5JY8exX
WP7+vC+GW4zyfxWEKoS8
=elNz
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH tip/core/rcu 42/55] rcu: Make rcu_torture_fqs() exit loops at end of test
From: Paul E. McKenney @ 2011-10-24 12:10 UTC (permalink / raw)
To: Josh Triplett
Cc: linux-kernel, mingo, laijs, dipankar, akpm, mathieu.desnoyers,
niv, tglx, peterz, rostedt, Valdis.Kletnieks, dhowells,
eric.dumazet, darren, patches
In-Reply-To: <20111017015329.GG19421@leaf>
On Sun, Oct 16, 2011 at 06:53:29PM -0700, Josh Triplett wrote:
> On Tue, Sep 06, 2011 at 11:00:36AM -0700, Paul E. McKenney wrote:
> > The rcu_torture_fqs() function can prevent the rcutorture tests from
> > completing, resulting in a hang. This commit therefore ensures that
> > rcu_torture_fqs() will exit its inner loops at the end of the test,
> > and also applies the newish ULONG_CMP_LT() macro to time comparisons.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> This seems like two entirely separate changes, which should go in
> separate commits.
Interesting. I was thinking of this as fixing hangs in rcutorture,
and was feeling somewhat bad about having the separate commit for the
part of the fix that I missed. ;-)
Thanx, Paul
^ permalink raw reply
* Information Request
From: Matias Seco @ 2011-10-24 12:10 UTC (permalink / raw)
To: reiserfs-devel
Greetings,
i found very interesting about testing this filesystem. Unfortunately
i got late with my project, because i couldn't find useful resources
from google for reiser4,
mainly because the reiser4's kernel Wiki was down due to maintenaince.
After time, i saw that the page still didn't return: this is why i
would like to ask you, if you can point me resources, to understand
how to configure the reiser4 on my HDD.
Salut, Matias
^ permalink raw reply
* Re: Kernel BUG unable to handle kernel NULL pointer dereference
From: Leonidas Spyropoulos @ 2011-10-24 12:10 UTC (permalink / raw)
To: dsterba; +Cc: Mitch Harder, linux-btrfs
In-Reply-To: <20111024115110.GG26547@ds.suse.cz>
On Mon, Oct 24, 2011 at 12:51 PM, David Sterba <dsterba@suse.cz> wrote:
> On Mon, Oct 24, 2011 at 12:33:05PM +0100, Leonidas Spyropoulos wrote:
>> Here is it, it's big and contains usless information..
>>
>> http://paste.pocoo.org/show/497299/
>
> not all that useless ... I saw another BUG earlier than the one you'v=
e
> reported:
>
> [31653.267742] ------------[ cut here ]------------
> [31653.267764] kernel BUG at fs/btrfs/extent-tree.c:5510!
> [31653.267773] invalid opcode: 0000 [#1] PREEMPT SMP
> [31653.267785] CPU 1
> [31653.267790] Modules linked in: vboxdrv ipv6 loop fuse adt7475 hwmo=
n_vid nouveau evdev uvcvideo hid_apple ttm videodev drm_kms_helper medi=
a v4l2_compat_ioctl32 drm snd_emu10k1 i2c_algo_bit mxm_wmi wmi pcspkr s=
nd_rawmidi snd_seq_device firewire_ohci emu10k1_gp edac_core psmouse sn=
d_util_mem edac_mce_amd k8temp firewire_core gameport snd_hwdep video s=
erio_raw crc_itu_t sg snd_intel8x0 snd_ac97_codec usbhid ac97_bus snd_p=
cm snd_timer hid snd floppy i2c_nforce2 thermal processor fan button so=
undcore i2c_core snd_page_alloc forcedeth btrfs zlib_deflate crc32c lib=
crc32c ext4 jbd2 crc16 ext3 jbd mbcache ohci_hcd ehci_hcd usbcore sr_mo=
d sd_mod cdrom sata_nv pata_amd libata scsi_mod
> [31653.267989]
> [31653.267995] Pid: 726, comm: btrfs-transacti Not tainted 3.0-ARCH #=
1 =A0 =A0/LP UT NF4 Expert
> [31653.268011] RIP: 0010:[<ffffffffa01a6263>] =A0[<ffffffffa01a6263>]=
run_clustered_refs+0x813/0x830 [btrfs]
> [31653.268045] RSP: 0018:ffff88013469bc70 =A0EFLAGS: 00010286
> [31653.268286] RAX: 00000000ffffffe4 RBX: ffff88012e406900 RCX: ffff8=
801378a6100
> [31653.268296] RDX: ffff88011513a0f0 RSI: 0000000000000000 RDI: 00000=
00000000000
> [31653.268306] RBP: ffff88013469bd50 R08: ffffffffffffffff R09: 00000=
00000000000
> [31653.268315] R10: ffff8801346f9800 R11: ffff88013735d3f0 R12: ffff8=
800a9bc7f00
> [31653.268325] R13: ffff88007b1d7e40 R14: ffff88011bd1e4b0 R15: 00000=
00000000000
> [31653.268341] FS: =A000007f8dcc527880(0000) GS:ffff88013fd00000(0000=
) knlGS:00000000f67567f0
> [31653.268367] CS: =A00010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [31653.268380] CR2: 00007f9059631550 CR3: 00000000a499c000 CR4: 00000=
000000006e0
> [31653.268394] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000=
00000000000
> [31653.268409] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000=
00000000400
> [31653.268424] Process btrfs-transacti (pid: 726, threadinfo ffff8801=
3469a000, task ffff880136c140b0)
> [31653.268443] Stack:
> [31653.268449] =A00000000000000000 0000000000000000 ffff880100000001 =
0000000000000000
> [31653.268473] =A00000000000000c2e 00000000a01dc529 0000000000000000 =
0000000000000002
> [31653.268495] =A00000000000000b9f 0000000000000c04 0000000000000000 =
ffff88013469bd90
> [31653.268515] Call Trace:
> [31653.268531] =A0[<ffffffffa01a6348>] btrfs_run_delayed_refs+0xc8/0x=
220 [btrfs]
> [31653.268549] =A0[<ffffffffa019421a>] ? btrfs_free_path+0x2a/0x40 [b=
trfs]
> [31653.268568] =A0[<ffffffffa01b86c3>] btrfs_commit_transaction+0x3c3=
/0x8a0 [btrfs]
> [31653.268581] =A0[<ffffffff8107f790>] ? abort_exclusive_wait+0xb0/0x=
b0
> [31653.268598] =A0[<ffffffffa01b13ed>] transaction_kthread+0x26d/0x29=
0 [btrfs]
> [31653.268617] =A0[<ffffffffa01b1180>] ? btrfs_congested_fn+0xd0/0xd0=
[btrfs]
> [31653.268627] =A0[<ffffffff8107ee3c>] kthread+0x8c/0xa0
> [31653.268638] =A0[<ffffffff813f5d64>] kernel_thread_helper+0x4/0x10
> [31653.268647] =A0[<ffffffff8107edb0>] ? kthread_worker_fn+0x190/0x19=
0
> [31653.268657] =A0[<ffffffff813f5d60>] ? gs_change+0x13/0x13
> [31653.268673] Code: e0 e9 12 f9 ff ff 0f 0b 80 fa b2 0f 84 bc f9 ff =
ff 0f 0b be 95 00 00 00 48 c7 c7 37 d0 20 a0 e8 54 65 eb e0 e9 04 f9 ff=
ff 0f 0b <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 66 66 66 66 66 66=
2e
> [31653.268928] RIP =A0[<ffffffffa01a6263>] run_clustered_refs+0x813/0=
x830 [btrfs]
> [31653.268956] =A0RSP <ffff88013469bc70>
> [31653.284196] ---[ end trace d5d8ee7634d1c36e ]---
>
> and it looks related to the print_leaf bug later (eg. mentiones same =
functions
> in the stacktrace and happens during commit).
>
> And judging from the rest of BUG's in the paste, the filesystem is in=
a bad
> shape. Some BUG_ON's seem to be triggered by ENOSPC (RAX containing 0=
xfff..e4).
>
>
> david
>
I am doing a backup of my current data as I write this mail (hopefully
it will finish without IO errors).
Will it help if I print the btrfs tree and post it somewhere?
I mean, since the system is funcionable, it could be useful to track
down the bug, no?
Regards
Leonidas
--=20
Caution: breathing may be hazardous to your health.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] ASoC: wm8940: Fix setting PLL Output clock division ratio
From: Mark Brown @ 2011-10-24 12:09 UTC (permalink / raw)
To: Axel Lin; +Cc: linux-kernel, Dimitris Papastamos, Liam Girdwood, alsa-devel
In-Reply-To: <1319427161.5773.3.camel@phoenix>
On Mon, Oct 24, 2011 at 11:32:41AM +0800, Axel Lin wrote:
> According to the datasheet:
> The PLL Output clock division ratio is controlled by BIT[5:4] of
> WM8940_GPIO register(08h).
> Current code read/write the WM8940_ADDCNTRL(07h) register which is wrong.
Applied this and patch 2, thanks.
^ permalink raw reply
* Re: [PATCH] ASoC: wm8996: Avoid a redundant i2c_get_clientdata call in wm8996_i2c_remove
From: Mark Brown @ 2011-10-24 12:08 UTC (permalink / raw)
To: Axel Lin; +Cc: linux-kernel, Dimitris Papastamos, Liam Girdwood, alsa-devel
In-Reply-To: <1319427072.5773.1.camel@phoenix>
On Mon, Oct 24, 2011 at 11:31:12AM +0800, Axel Lin wrote:
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ASoC: wm8996: Avoid a redundant i2c_get_clientdata call in wm8996_i2c_remove
From: Mark Brown @ 2011-10-24 12:08 UTC (permalink / raw)
To: Axel Lin; +Cc: Dimitris Papastamos, alsa-devel, linux-kernel, Liam Girdwood
In-Reply-To: <1319427072.5773.1.camel@phoenix>
On Mon, Oct 24, 2011 at 11:31:12AM +0800, Axel Lin wrote:
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ASoC: wm8400: Fix setting Fout clock divider for FLL Control 4
From: Mark Brown @ 2011-10-24 12:08 UTC (permalink / raw)
To: Axel Lin; +Cc: linux-kernel, Dimitris Papastamos, Liam Girdwood, alsa-devel
In-Reply-To: <1319294907.2678.2.camel@phoenix>
On Sat, Oct 22, 2011 at 10:48:27PM +0800, Axel Lin wrote:
> What we want here is to clear the WM8400_FLL_OUTDIV_MASK bits then
> OR with factors.outdiv.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ASoC: wm8400: Fix setting Fout clock divider for FLL Control 4
From: Mark Brown @ 2011-10-24 12:08 UTC (permalink / raw)
To: Axel Lin; +Cc: Dimitris Papastamos, alsa-devel, linux-kernel, Liam Girdwood
In-Reply-To: <1319294907.2678.2.camel@phoenix>
On Sat, Oct 22, 2011 at 10:48:27PM +0800, Axel Lin wrote:
> What we want here is to clear the WM8400_FLL_OUTDIV_MASK bits then
> OR with factors.outdiv.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH tip/core/rcu 36/55] rcu: Prevent early boot set_need_resched() from __rcu_pending()
From: Paul E. McKenney @ 2011-10-24 12:07 UTC (permalink / raw)
To: Josh Triplett
Cc: linux-kernel, mingo, laijs, dipankar, akpm, mathieu.desnoyers,
niv, tglx, peterz, rostedt, Valdis.Kletnieks, dhowells,
eric.dumazet, darren, patches, Paul E. McKenney
In-Reply-To: <20111017014915.GE19421@leaf>
On Sun, Oct 16, 2011 at 06:49:15PM -0700, Josh Triplett wrote:
> On Tue, Sep 06, 2011 at 11:00:30AM -0700, Paul E. McKenney wrote:
> > From: Paul E. McKenney <paul.mckenney@linaro.org>
> >
> > There isn't a whole lot of point in poking the scheduler before there
> > are other tasks to switch to. This commit therefore adds a check
> > for rcu_scheduler_fully_active in __rcu_pending() to suppress any
> > pre-scheduler calls to set_need_resched(). The downside of this approach
> > is additional runtime overhead in a reasonably hot code path.
>
> If you're concerned about the runtime overhead, this does seem like a
> perfect candidate for jump labels.
I have added this to my todo list, but would welcome a patch.
Thanx, Paul
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH] batman-adv: add sanity check when removing global tts
From: Marek Lindner @ 2011-10-24 12:07 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
In-Reply-To: <4EA3E181.2020102@fisher-privat.net>
On Sunday, October 23, 2011 11:42:25 Alexey Fisher wrote:
> On 23.10.2011 11:38, Antonio Quartulli wrote:
> > Hello,
> >
> > On Wed, Oct 19, 2011 at 10:28:26AM +0200, Simon Wunderlich wrote:
> >> After removing the batman-adv module, the hash may be already gone
> >> when tt_global_del_orig() tries to clean the hash. This patch adds
> >> a sanity check to avoid this.
> >>
> >> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
> >> ---
> >
> > I got a feedback on IRC from fishor_ who said that the patch solved the
> > kernel panic problem on module unload and on soft_iface deactivating.
> >
> > Thank you for the patch Simon!
>
> tested-by: Alexey Fisher <bug-track@fisher-privat.net>
Patch was applied in revision 4c7d468.
Thanks,
Marek
^ permalink raw reply
* Re: [PATCH tip/core/rcu 31/55] rcu: Make rcu_implicit_dynticks_qs() locals be correct size
From: Paul E. McKenney @ 2011-10-24 12:00 UTC (permalink / raw)
To: Josh Triplett
Cc: linux-kernel, mingo, laijs, dipankar, akpm, mathieu.desnoyers,
niv, tglx, peterz, rostedt, Valdis.Kletnieks, dhowells,
eric.dumazet, darren, patches
In-Reply-To: <20111017014350.GD19421@leaf>
On Sun, Oct 16, 2011 at 06:43:50PM -0700, Josh Triplett wrote:
> On Tue, Sep 06, 2011 at 11:00:25AM -0700, Paul E. McKenney wrote:
> > When the ->dynticks field in the rcu_dynticks structure changed to an
> > atomic_t, its size on 64-bit systems changed from 64 bits to 32 bits.
> > The local variables in rcu_implicit_dynticks_qs() need to change as
> > well, hence this commit.
>
> If an atomic_t always holds 32-bits, which it appears to, then shouldn't
> this use u32 rather than unsigned int?
The atomic_t definition is "int", and I need "unsigned int" to avoid
integer overflow.
But it might make sense to make atomic_t s32, in which case I would
use u32. I don't feel very strongly about it either way, because "int"
is also defined to be 32 bits. Maybe I should put such a patch forward
later on.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH] gpiolib: Provide a definition of struct gpio for the stub gpiolib
From: Mark Brown @ 2011-10-24 12:07 UTC (permalink / raw)
To: Grant Likely; +Cc: Grant Likely, linux-kernel
In-Reply-To: <20111024120120.GO8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 02:01:20PM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 01:27:29PM +0200, Mark Brown wrote:
> > This makes the stub gpio_request_array() much more usable as drivers can
> > declare struct gpio variables.
> > Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Shouldn't this patch remove the definition from
> include/asm-generic/gpio.h at the same time?
Both the original forward declaration and the new definition are within
the !GPIOLIB case of the #defines, it's just a minimal patch moving the
undefined forward declaration to a defintion. I didn't want to worry
about reading the individual users to figure out if they had separate
defintions separately to the work to get them all moved over to gpiolib.
^ permalink raw reply
* [PATCH] [TRIVIAL] netfilter: make physdev_mt more readable
From: Richard Weinberger @ 2011-10-24 12:06 UTC (permalink / raw)
To: netfilter-devel
Cc: netdev, linux-kernel, trivial, davem, kaber, Richard Weinberger
Signed-off-by: Richard Weinberger <richard@nod.at>
---
net/netfilter/xt_physdev.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/xt_physdev.c b/net/netfilter/xt_physdev.c
index d7ca16b..eabb751 100644
--- a/net/netfilter/xt_physdev.c
+++ b/net/netfilter/xt_physdev.c
@@ -28,12 +28,12 @@ physdev_mt(const struct sk_buff *skb, struct xt_action_param *par)
const struct xt_physdev_info *info = par->matchinfo;
unsigned long ret;
const char *indev, *outdev;
- const struct nf_bridge_info *nf_bridge;
+ const struct nf_bridge_info *nf_bridge = skb->nf_bridge;
/* Not a bridged IP packet or no info available yet:
* LOCAL_OUT/mangle and LOCAL_OUT/nat don't know if
* the destination device will be a bridge. */
- if (!(nf_bridge = skb->nf_bridge)) {
+ if (!nf_bridge) {
/* Return MATCH if the invert flags of the used options are on */
if ((info->bitmask & XT_PHYSDEV_OP_BRIDGED) &&
!(info->invert & XT_PHYSDEV_OP_BRIDGED))
--
1.7.7
^ permalink raw reply related
* Re: [PATCH bluez] add get_le/get_be helpers
From: Vinicius Gomes @ 2011-10-24 12:06 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Emeltchenko Andrei, linux-bluetooth
In-Reply-To: <1319457038.15441.230.camel@aeonflux>
Hi Marcel,
On Mon, Oct 24, 2011 at 1:50 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Vinicius,
>
>> Sorry if this comes too late, but here's an idea:
>>
>> How about changing the name of the functions to something a little
>> more high level, for example: in attrib/att.h we have
>> att_{get,put}_u16() that uses the byte order defined in the ATT spec
>> (little endian).
>>
>> So my suggestion is to have bt_{get,put}_u*() and sdp_{get,put}_u*
>> functions (perhaps also no_{get,put}_u* for cases when we use the host
>> byte order). The bt_ functions will be used for everything that uses
>> the Bluetooth byte order and the sdp_ ones for SDP, which is the only
>> case of Big Endian defined by Bluetooth, correct me if I am wrong.
>
> lets not try to be too smart. We want the code clearly identify what
> endian is expected. Same as the kernel handles this.
>
After reading Szymon comments I came to the same conclusion. This more
explicit approach makes more sense.
> Regards
>
> Marcel
>
>
>
Cheers,
--
Vinicius
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: wm8940: Fix a typo for the mask of setting WM8940_BCLKDIV
From: Girdwood, Liam @ 2011-10-24 12:06 UTC (permalink / raw)
To: Axel Lin; +Cc: linux-kernel, Mark Brown, Dimitris Papastamos, alsa-devel
In-Reply-To: <1319427235.5773.4.camel@phoenix>
On 24 October 2011 04:33, Axel Lin <axel.lin@gmail.com> wrote:
> The registers are 16 bits, thus remove an extra F for the mask.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> ---
> sound/soc/codecs/wm8940.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/sound/soc/codecs/wm8940.c b/sound/soc/codecs/wm8940.c
> index 3cc3bce..fec3892 100644
> --- a/sound/soc/codecs/wm8940.c
> +++ b/sound/soc/codecs/wm8940.c
> @@ -619,7 +619,7 @@ static int wm8940_set_dai_clkdiv(struct snd_soc_dai *codec_dai,
>
> switch (div_id) {
> case WM8940_BCLKDIV:
> - reg = snd_soc_read(codec, WM8940_CLOCK) & 0xFFEF3;
> + reg = snd_soc_read(codec, WM8940_CLOCK) & 0xFEF3;
> ret = snd_soc_write(codec, WM8940_CLOCK, reg | (div << 2));
> break;
> case WM8940_MCLKDIV:
> --
Acked-by: Liam Girdwood <lrg@ti.com>
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: wm8940: Fix a typo for the mask of setting WM8940_BCLKDIV
From: Girdwood, Liam @ 2011-10-24 12:06 UTC (permalink / raw)
To: Axel Lin; +Cc: Dimitris Papastamos, alsa-devel, Mark Brown, linux-kernel
In-Reply-To: <1319427235.5773.4.camel@phoenix>
On 24 October 2011 04:33, Axel Lin <axel.lin@gmail.com> wrote:
> The registers are 16 bits, thus remove an extra F for the mask.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> ---
> sound/soc/codecs/wm8940.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/sound/soc/codecs/wm8940.c b/sound/soc/codecs/wm8940.c
> index 3cc3bce..fec3892 100644
> --- a/sound/soc/codecs/wm8940.c
> +++ b/sound/soc/codecs/wm8940.c
> @@ -619,7 +619,7 @@ static int wm8940_set_dai_clkdiv(struct snd_soc_dai *codec_dai,
>
> switch (div_id) {
> case WM8940_BCLKDIV:
> - reg = snd_soc_read(codec, WM8940_CLOCK) & 0xFFEF3;
> + reg = snd_soc_read(codec, WM8940_CLOCK) & 0xFEF3;
> ret = snd_soc_write(codec, WM8940_CLOCK, reg | (div << 2));
> break;
> case WM8940_MCLKDIV:
> --
Acked-by: Liam Girdwood <lrg@ti.com>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Jan Kiszka @ 2011-10-24 12:06 UTC (permalink / raw)
To: Avi Kivity; +Cc: Marcelo Tosatti, kvm, Michael S. Tsirkin
In-Reply-To: <4EA54759.902@redhat.com>
On 2011-10-24 13:09, Avi Kivity wrote:
> On 10/24/2011 12:19 PM, Jan Kiszka wrote:
>>>
>>> With the new feature it may be worthwhile, but I'd like to see the whole
>>> thing, with numbers attached.
>>
>> It's not a performance issue, it's a resource limitation issue: With the
>> new API we can stop worrying about user space device models consuming
>> limited IRQ routes of the KVM subsystem.
>>
>
> Only if those devices are in the same process (or have access to the
> vmfd). Interrupt routing together with irqfd allows you to disaggregate
> the device model. Instead of providing a competing implementation with
> new limitations, we need to remove the limitations of the old
> implementation.
That depends on where we do the cut. Currently we let the IRQ source
signal an abstract edge on a pre-allocated pseudo IRQ line. But we
cannot build correct MSI-X on top of the current irqfd model as we lack
the level information (for PBA emulation). *) So we either need to
extend the existing model anyway -- or push per-vector masking back to
the IRQ source. In the latter case, it would be a very good chance to
give up on limited pseudo GSIs with static routes and do MSI messaging
from external IRQ sources to KVM directly.
But all those considerations affect different APIs than what I'm
proposing here. We will always need a way to inject MSIs in the context
of the VM as there will always be scenarios where devices are better run
in that very same context, for performance or simplicity or whatever
reasons. E.g., I could imagine that one would like to execute an
emulated IRQ remapper rather in the hypervisor context than
"over-microkernelized" in a separate process.
Jan
*) Realized this while trying to generalize the proposed MSI-X MMIO
acceleration for assigned devices to arbitrary device models, vhost-net,
and specifically vfio.
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ 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.