[PATCH] firewire net: Ensure checksumming in upper layer.
It is wrong to set skb->ip_summed to CHECKSUM_UNNECESSARY unless the device has already checked it. Signed-off-by: YOSHIFUJI Hideaki --- drivers/firewire/net.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c index e7a711f5..df6a1ca 100644 --- a/drivers/firewire/net.c +++ b/drivers/firewire/net.c @@ -520,7 +520,7 @@ static int fwnet_finish_incoming_packet(struct net_device *net, dev = netdev_priv(net); /* Write metadata, and then pass to the receive level */ skb->dev = net; - skb->ip_summed = CHECKSUM_UNNECESSARY; /* don't check it */ + skb->ip_summed = CHECKSUM_NONE; /* * Parse the encapsulation header. This actually does the job of -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: iwlwifi: regression in 3.8-rc4 and 3.7.3
On Sun, 20 Jan 2013, Grumbach, Emmanuel wrote: > > > > On Sun, Jan 20, 2013 at 6:56 AM, Hugh Dickins wrote: > > > After sending the first 2MB, scp over wireless becomes unbearably > > > slow, with frequent stalls: on this ThinkPad T420s running 3.8-rc4 or > > > 3.7.3. > > > Not always, but often. > > > > > > > There is one pending iwlwifi-fixes, dunno if it will fix your issue. > > [1] http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi- > > fixes.git;a=commitdiff;h=c3e5d7181afb66657393066bccce0956fab09ab3 > > Right - so the 2 patches are unrelated, and the one Sedat is pointing at is > relevant for 3.8 only. It fixes a bug that has been introduced in 3.8. Yes, I have now given that one a try, but it does not affect my issue. > Regarding the issue Hugh is suffering from, I have to say that I am a little > confused since I am pretty sure the patch is right. Now, it might uncover > other pre-existing bugs. All I can say is that I don't think that reverting > the patch is *so* problematic since the patch really wants to solve a rare > case. If it causes issues, we can simply revert it. It only means that when I > will get a little bit of time, I might need to ask you a few logs. Thanks for > the report (and the bisection). Sure, let me know what to do, once you have time to investigate. So far as I know, I'm the first to notice: so we can probably leave it in 3.8-rc for now, until/unless it gives wider trouble. But reverting from 3.7-stable soon would be a good idea, regressions there being more tiresome. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: iwlwifi: regression in 3.8-rc4 and 3.7.3
>
> On Sun, Jan 20, 2013 at 6:56 AM, Hugh Dickins wrote:
> > After sending the first 2MB, scp over wireless becomes unbearably
> > slow, with frequent stalls: on this ThinkPad T420s running 3.8-rc4 or 3.7.3.
> > Not always, but often.
> >
>
> There is one pending iwlwifi-fixes, dunno if it will fix your issue.
> [1] http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-
> fixes.git;a=commitdiff;h=c3e5d7181afb66657393066bccce0956fab09ab3
Right - so the 2 patches are unrelated, and the one Sedat is pointing at is
relevant for 3.8 only. It fixes a bug that has been introduced in 3.8.
Regarding the issue Hugh is suffering from, I have to say that I am a little
confused since I am pretty sure the patch is right. Now, it might uncover other
pre-existing bugs. All I can say is that I don't think that reverting the patch
is *so* problematic since the patch really wants to solve a rare case. If it
causes issues, we can simply revert it. It only means that when I will get a
little bit of time, I might need to ask you a few logs. Thanks for the report
(and the bisection).
-
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH v2 00/76] Synopsys ARC Linux kernel Port
On 01/18/2013 04:24 AM, Vineet Gupta wrote: This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700 processor family (750D and 770D) from Synopsys. I would be greatful for further review and feedback. One thing: ARC, as I understand it, is a whole family of architectures, which mostly have in common their origin at Synopsys. Can we make this arch/arc700 since that is what it is? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iwlwifi: regression in 3.8-rc4 and 3.7.3
On Sun, Jan 20, 2013 at 6:56 AM, Hugh Dickins wrote:
> After sending the first 2MB, scp over wireless becomes unbearably slow,
> with frequent stalls: on this ThinkPad T420s running 3.8-rc4 or 3.7.3.
> Not always, but often.
>
There is one pending iwlwifi-fixes, dunno if it will fix your issue.
- Sedat -
[1]
http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-fixes.git;a=commitdiff;h=c3e5d7181afb66657393066bccce0956fab09ab3
> Bisection led to commit f590dcec944552f9a4a61155810f3abd17d6465d
> "iwlwifi: fix the reclaimed packet tracking upon flush queue"
> (below); and indeed backing that out brings them back to speed.
>
> Here are the "iwlwifi" lines from my dmesg:
> [1.936640] iwlwifi :03:00.0: irq 44 for MSI/MSI-X
> [8.384905] iwlwifi :03:00.0: loaded firmware version 9.221.4.1 build
> 25532
> [8.406425] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUG disabled
> [8.427099] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
> [8.447888] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
> [8.468369] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
> [8.489008] iwlwifi :03:00.0: CONFIG_IWLWIFI_P2P disabled
> [8.509588] iwlwifi :03:00.0: Detected Intel(R) Centrino(R) Ultimate-N
> 6300 AGN, REV=0x74
> [8.531309] iwlwifi :03:00.0: L1 Enabled; Disabling L0S
> [9.891162] iwlwifi :03:00.0: L1 Enabled; Disabling L0S
> [9.891399] iwlwifi :03:00.0: Radio type=0x0-0x3-0x1
> [ 10.260205] iwlwifi :03:00.0: L1 Enabled; Disabling L0S
> [ 10.260405] iwlwifi :03:00.0: Radio type=0x0-0x3-0x1
>
> Thanks,
> Hugh
>
> commit f590dcec944552f9a4a61155810f3abd17d6465d
> Author: Emmanuel Grumbach
> Date: Mon Dec 31 09:26:10 2012 +0200
>
> iwlwifi: fix the reclaimed packet tracking upon flush queue
>
> There's a bug in the currently released firmware version,
> the sequence control in the Tx response isn't updated in
> all cases. Take it from the packet as a workaround.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Emmanuel Grumbach
> Signed-off-by: Johannes Berg
>
> diff --git a/drivers/net/wireless/iwlwifi/dvm/tx.c
> b/drivers/net/wireless/iwlwifi/dvm/tx.c
> index da21328..a790599 100644
> --- a/drivers/net/wireless/iwlwifi/dvm/tx.c
> +++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
> @@ -1151,13 +1151,6 @@ int iwlagn_rx_reply_tx(struct iwl_priv *priv, struct
> iwl_rx_cmd_buffer *rxb,
> next_reclaimed = ssn;
> }
>
> - if (tid != IWL_TID_NON_QOS) {
> - priv->tid_data[sta_id][tid].next_reclaimed =
> - next_reclaimed;
> - IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
> - next_reclaimed);
> - }
> -
> iwl_trans_reclaim(priv->trans, txq_id, ssn, );
>
> iwlagn_check_ratid_empty(priv, sta_id, tid);
> @@ -1208,11 +1201,28 @@ int iwlagn_rx_reply_tx(struct iwl_priv *priv, struct
> iwl_rx_cmd_buffer *rxb,
> if (!is_agg)
> iwlagn_non_agg_tx_status(priv, ctx,
> hdr->addr1);
>
> + /*
> +* W/A for FW bug - the seq_ctl isn't updated when the
> +* queues are flushed. Fetch it from the packet itself
> +*/
> + if (!is_agg && status == TX_STATUS_FAIL_FIFO_FLUSHED)
> {
> + next_reclaimed = le16_to_cpu(hdr->seq_ctrl);
> + next_reclaimed =
> + SEQ_TO_SN(next_reclaimed + 0x10);
> + }
> +
> is_offchannel_skb =
> (info->flags & IEEE80211_TX_CTL_TX_OFFCHAN);
> freed++;
> }
>
> + if (tid != IWL_TID_NON_QOS) {
> + priv->tid_data[sta_id][tid].next_reclaimed =
> + next_reclaimed;
> + IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
> + next_reclaimed);
> + }
> +
> WARN_ON(!is_agg && freed != 1);
>
> /*
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] gpio: introduce descriptor-based interface
Hi Steven, On 01/18/2013 01:50 AM, Steven King wrote: Well, my concern is the small, single chip platforms with limited ram and speeds measured in MHz. My goal was that these platforms that had very basic gpio needs, no offboard gpio, just toggling a few pins for spi or whatever, could do that without pulling in a bunch of code they dont need. I realize that for x86 or arm people with their giga Hz cpus with gigabytes of ram, its no big deal, but my little 60 MHz coldfire v2s with only 16 megs of ram (and even more constraining, 2 megs of flash) need all the help they can get. Running readelf on gpiolib.o built for Tegra, here are the footprints: .text: 9412B .data: 260B .bss: 12312B .rodata: 268B Total: 22252B or 22KB. ... of which more than half is the BSS section which consists of a static array of 1024 GPIO descriptors, an arbitrary number that you can tune and is way too large even for Tegra (but we have to use these gigabytes somehow). Say you only need to use 256 GPIOs and .bss is down to ~3KB, for a total overhead of 15kB or 0.09% of your 16MB which, in perspective, suddenly seem gigantic. :) If you are concerned about the additional indirection that GPIOlib introduces and the potential slowdown for bitbanging, you can always define custom gpio_set_value() and gpio_get_value() macros to shortcut GPIOlib when the GPIO is in the range you want performance for. I haven't been keeping up with the kernel list of late, can someone point me to what''s being discussed so I can see what were talking about here? Arnd explained it already, but basically we'd like to consolidate the GPIO subsystem around GPIOlib and introduce safer interfaces (while preserving backward compatibility). Good progress in that direction would be achieved if all users of the GENERIC_GPIO interface relied on GPIOlib (making GENERIC_GPIO require GPIOLIB). Actually the question of switching to GPIOlib is only worth being asked if you are making use of drivers that require GENERIC_GPIO. If this is not the case and your GPIOs are only used by your own platform code, you can always give up using defining GENERIC_GPIO and continue implementing them your own way. Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
iwlwifi: regression in 3.8-rc4 and 3.7.3
After sending the first 2MB, scp over wireless becomes unbearably slow,
with frequent stalls: on this ThinkPad T420s running 3.8-rc4 or 3.7.3.
Not always, but often.
Bisection led to commit f590dcec944552f9a4a61155810f3abd17d6465d
"iwlwifi: fix the reclaimed packet tracking upon flush queue"
(below); and indeed backing that out brings them back to speed.
Here are the "iwlwifi" lines from my dmesg:
[1.936640] iwlwifi :03:00.0: irq 44 for MSI/MSI-X
[8.384905] iwlwifi :03:00.0: loaded firmware version 9.221.4.1 build
25532
[8.406425] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUG disabled
[8.427099] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[8.447888] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[8.468369] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
[8.489008] iwlwifi :03:00.0: CONFIG_IWLWIFI_P2P disabled
[8.509588] iwlwifi :03:00.0: Detected Intel(R) Centrino(R) Ultimate-N
6300 AGN, REV=0x74
[8.531309] iwlwifi :03:00.0: L1 Enabled; Disabling L0S
[9.891162] iwlwifi :03:00.0: L1 Enabled; Disabling L0S
[9.891399] iwlwifi :03:00.0: Radio type=0x0-0x3-0x1
[ 10.260205] iwlwifi :03:00.0: L1 Enabled; Disabling L0S
[ 10.260405] iwlwifi :03:00.0: Radio type=0x0-0x3-0x1
Thanks,
Hugh
commit f590dcec944552f9a4a61155810f3abd17d6465d
Author: Emmanuel Grumbach
Date: Mon Dec 31 09:26:10 2012 +0200
iwlwifi: fix the reclaimed packet tracking upon flush queue
There's a bug in the currently released firmware version,
the sequence control in the Tx response isn't updated in
all cases. Take it from the packet as a workaround.
Cc: sta...@vger.kernel.org
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
diff --git a/drivers/net/wireless/iwlwifi/dvm/tx.c
b/drivers/net/wireless/iwlwifi/dvm/tx.c
index da21328..a790599 100644
--- a/drivers/net/wireless/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
@@ -1151,13 +1151,6 @@ int iwlagn_rx_reply_tx(struct iwl_priv *priv, struct
iwl_rx_cmd_buffer *rxb,
next_reclaimed = ssn;
}
- if (tid != IWL_TID_NON_QOS) {
- priv->tid_data[sta_id][tid].next_reclaimed =
- next_reclaimed;
- IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
- next_reclaimed);
- }
-
iwl_trans_reclaim(priv->trans, txq_id, ssn, );
iwlagn_check_ratid_empty(priv, sta_id, tid);
@@ -1208,11 +1201,28 @@ int iwlagn_rx_reply_tx(struct iwl_priv *priv, struct
iwl_rx_cmd_buffer *rxb,
if (!is_agg)
iwlagn_non_agg_tx_status(priv, ctx, hdr->addr1);
+ /*
+* W/A for FW bug - the seq_ctl isn't updated when the
+* queues are flushed. Fetch it from the packet itself
+*/
+ if (!is_agg && status == TX_STATUS_FAIL_FIFO_FLUSHED) {
+ next_reclaimed = le16_to_cpu(hdr->seq_ctrl);
+ next_reclaimed =
+ SEQ_TO_SN(next_reclaimed + 0x10);
+ }
+
is_offchannel_skb =
(info->flags & IEEE80211_TX_CTL_TX_OFFCHAN);
freed++;
}
+ if (tid != IWL_TID_NON_QOS) {
+ priv->tid_data[sta_id][tid].next_reclaimed =
+ next_reclaimed;
+ IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
+ next_reclaimed);
+ }
+
WARN_ON(!is_agg && freed != 1);
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
On 01/20/2013 01:26 PM, Alexandre Courbot wrote: > On Sun, Jan 20, 2013 at 12:38 PM, Mark Zhang wrote: >> So this is a non power sequence version of backlight & panel enabling, >> isn't it? I remember we talked about this several days ago and you >> mentioned kernel guys want an ad-hoc version(power sequence logics >> inside driver, not in DT) and I believe this is it, right? > > Basically, yes - I still think power-seqs could be useful here > (especially after seeing the size of these sub-drivers if you want to > do error checking properly) and plan to give it another shot without > DT, but this will not happen soon since we need to do some GPIO > redesign before. You can see what's wrong in the init() function of > the subdriver: we call a device tree function to obtain the GPIO as > there is no get function. > Okay. I think I got the picture. I'll read the codes when I'm free and I think I'll understand this better after that. >> I think finally I can enable Tegra30 cardhu's display after this patch >> merged. > > Yes, feel free to write a subdriver for Cardhu if you like - I'd like > to see all T20 and T30 boards supported by the time this gets merged. > Yep, I can try to do that. I'll let you know if I have problems. Mark > Thanks, > Alex. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
On Sun, Jan 20, 2013 at 12:38 PM, Mark Zhang wrote: > So this is a non power sequence version of backlight & panel enabling, > isn't it? I remember we talked about this several days ago and you > mentioned kernel guys want an ad-hoc version(power sequence logics > inside driver, not in DT) and I believe this is it, right? Basically, yes - I still think power-seqs could be useful here (especially after seeing the size of these sub-drivers if you want to do error checking properly) and plan to give it another shot without DT, but this will not happen soon since we need to do some GPIO redesign before. You can see what's wrong in the init() function of the subdriver: we call a device tree function to obtain the GPIO as there is no get function. > I think finally I can enable Tegra30 cardhu's display after this patch > merged. Yes, feel free to write a subdriver for Cardhu if you like - I'd like to see all T20 and T30 boards supported by the time this gets merged. Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPsec AH use of ahash
On Sat, 2013-01-19 at 05:30 -0500, Tom St Denis wrote: > For those of us who do Kernel development during business hours it's > hard to justify the work when the path to mainline is convoluted and > landmined. Sounds as though any patches you submit land on your dinner plate just like potatoes. Hand the cook a pot of half peeled potatoes, he/she may say try again. The result of a little extra effort is tastier taters for everybody feasting at the common table.. including you. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: crash in ocfs2_fast_symlink_readpage in kernel 3.5.0
On Tue, Oct 2, 2012 at 8:41 PM, Bret Towe wrote: > On Sun, Jul 22, 2012 at 1:16 PM, Bret Towe wrote: >> just booted a fresh 3.5 kernel and got the following on login via gdm >> on the client computer >> didn't see any crashes yet on any other computer but didn't give it >> long to try after seeing this >> let me know if you need more info >> this client is running debian wheezy 64bit >> >> Jul 22 12:48:38 ghoststar kernel: [ 382.563886] general protection >> fault: [#1] PREEMPT SMP >> Jul 22 12:48:38 ghoststar kernel: [ 382.563918] CPU 0 >> Jul 22 12:48:38 ghoststar kernel: [ 382.563927] Modules linked in: >> ocfs2 quota_tree jbd2 sch_fq_codel xt_LOG xt_tcpudp nf_conntrack_ipv6 >> nf_defrag_ipv6 xt_state nf_conntrack ip6table_mangle ip6table_filter >> ip6_tables x_tables cpufreq_userspace cpufreq_powersave >> cpufreq_conservative binfmt_misc iscsi_tcp libiscsi_tcp libiscsi >> scsi_transport_iscsi tcp_bic ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm >> ocfs2_nodemanager nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc >> af_packet ocfs2_stack_user dlm sctp crc32c libcrc32c ipv6 >> ocfs2_stackglue configfs loop fuse aoe msr joydev snd_hda_codec_hdmi >> snd_hda_codec_realtek evdev snd_hda_intel snd_hda_codec snd_hwdep >> snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_seq_dummy >> snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq >> powernow_k8 mperf kvm_amd kvm snd_seq_device snd_timer psmouse pcspkr >> serio_raw asus_atk0110 snd k10temp soundcore i2c_piix4 button >> processor dm_mod uas usb_storage firewire_ohci r8169 firewire_core >> crc_itu_t [last unloaded: scsi_wait_scan] >> Jul 22 12:48:38 ghoststar kernel: [ 382.564352] >> Jul 22 12:48:38 ghoststar kernel: [ 382.564354] Pid: 3690, comm: >> fbsetbg Not tainted 3.5.0+ #4 System manufacturer System Product >> Name/M3A78-EM >> Jul 22 12:48:38 ghoststar kernel: [ 382.564395] RIP: >> 0010:[] [] strnlen+0xd/0x40 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564428] RSP: >> :88011ed31b78 EFLAGS: 00010202 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564449] RAX: 880122caac00 >> RBX: 495441c589455601 RCX: 0f3f >> Jul 22 12:48:38 ghoststar kernel: [ 382.564476] RDX: 0001 >> RSI: 0f40 RDI: 495441c589455601 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564503] RBP: 88011ed31b78 >> R08: 88011ed31b50 R09: a0588fa0 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564530] R10: >> R11: 0001 R12: ea00046ee040 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564557] R13: 88011e0ef138 >> R14: ea00046ee040 R15: a05e2a50 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564585] FS: >> 7f6632782700() GS:88012fc0() >> knlGS: >> Jul 22 12:48:38 ghoststar kernel: [ 382.564616] CS: 0010 DS: >> ES: CR0: 8005003b >> Jul 22 12:48:38 ghoststar kernel: [ 382.564638] CR2: 7f24b14ea340 >> CR3: 00011ee66000 CR4: 07f0 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564665] DR0: >> DR1: DR2: >> Jul 22 12:48:38 ghoststar kernel: [ 382.564692] DR3: >> DR6: 0ff0 DR7: 0400 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564719] Process fbsetbg (pid: >> 3690, threadinfo 88011ed3, task 880122382c80) >> Jul 22 12:48:38 ghoststar kernel: [ 382.564750] Stack: >> Jul 22 12:48:38 ghoststar kernel: [ 382.564758] 88011ed31bc8 >> a05e2aac 88011e0ef278 000200da >> Jul 22 12:48:38 ghoststar kernel: [ 382.564790] 88011ed31bc8 >> 810db189 88011e0ef278 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564822] 88011e0ef278 >> 000200da 88011ed31c28 810db225 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564854] Call Trace: >> Jul 22 12:48:38 ghoststar kernel: [ 382.564892] [] >> ocfs2_fast_symlink_readpage+0x5c/0x1a0 [ocfs2] >> Jul 22 12:48:38 ghoststar kernel: [ 382.564922] [] >> ? add_to_page_cache_lru+0x29/0x40 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564947] [] >> do_read_cache_page+0x85/0x180 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564971] [] >> read_cache_page_async+0x14/0x20 >> Jul 22 12:48:38 ghoststar kernel: [ 382.564995] [] >> read_cache_page+0x9/0x20 >> Jul 22 12:48:38 ghoststar kernel: [ 382.565018] [] >> page_getlink.isra.21+0x25/0x80 >> Jul 22 12:48:38 ghoststar kernel: [ 382.565042] [] >> page_follow_link_light+0x21/0x40 >> Jul 22 12:48:38 ghoststar kernel: [ 382.565066] [] >> link_path_walk+0x48b/0x950 >> Jul 22 12:48:38 ghoststar kernel: [ 382.565089] [] >> path_lookupat+0x52/0x7c0 >> Jul 22 12:48:38 ghoststar kernel: [ 382.565112] [] >> ? xfs_file_aio_read+0x187/0x370 >> Jul 22 12:48:38 ghoststar kernel: [ 382.565136] [] >> do_path_lookup+0x2c/0xc0 >> Jul 22 12:48:38 ghoststar kernel: [ 382.565159] [] >> ? getname_flags+0x4e/0xf0 >> Jul 22 12:48:38 ghoststar kernel: [ 382.565181] [] >>
Re: [RFC PATCH 0/2] sched: simplify the select_task_rq_fair()
On Thu, 2013-01-17 at 13:55 +0800, Michael Wang wrote:
> Hi, Mike
>
> I've send out the v2, which I suppose it will fix the below BUG and
> perform better, please do let me know if it still cause issues on your
> arm7 machine.
s/arm7/aim7
Someone swiped half of CPUs/ram, so the box is now 2 10 core nodes vs 4.
stock scheduler knobs
3.8-wang-v2 avg 3.8-virgin
avgvs wang
Tasksjobs/min
1 436.29435.66435.97435.97437.86441.69
440.09439.88 1.008
5 2361.65 2356.14 2350.66 2356.15 2416.27 2563.45
2374.61 2451.44 1.040
10 4767.90 4764.15 4779.18 4770.41 4946.94 4832.54
4828.69 4869.39 1.020
20 9672.79 9703.76 9380.80 9585.78 9634.34 9672.79
9727.13 9678.08 1.009
4019162.06 19207.61 19299.36 19223.01 19268.68 19192.40
19056.60 19172.56 .997
8037610.55 37465.22 37465.22 37513.66 37263.64 37120.98
37465.22 37283.28 .993
16069306.65 69655.17 69257.14 69406.32 69257.14 69306.65
69257.14 69273.64 .998
320 111512.36 109066.37 111256.45 110611.72 108395.75 107913.19
108335.20 108214.71 .978
640 142850.83 148483.92 150851.81 147395.52 151974.92 151263.65
151322.67 151520.41 1.027
128052788.89 52706.39 67280.77 57592.01 189931.44 189745.60
189792.02 189823.02 3.295
256075403.91 52905.91 45196.21 57835.34 217368.64 217582.05
217551.54 217500.74 3.760
sched_latency_ns = 24ms
sched_min_granularity_ns = 8ms
sched_wakeup_granularity_ns = 10ms
3.8-wang-v2 avg 3.8-virgin
avgvs wang
Tasksjobs/min
1 436.29436.60434.72435.87434.41439.77
438.81437.66 1.004
5 2382.08 2393.36 2451.46 2408.96 2451.46 2453.44
2425.94 2443.61 1.014
10 5029.05 4887.10 5045.80 4987.31 4844.12 4828.69
4844.12 4838.97 .970
20 9869.71 9734.94 9758.45 9787.70 9513.34 9611.42
9565.90 9563.55 .977
4019146.92 19146.92 19192.40 19162.08 18617.51 18603.22
18517.95 18579.56 .969
8037177.91 37378.57 37292.31 37282.93 36451.13 36179.10
36233.18 36287.80 .973
16070260.87 69109.05 69207.71 69525.87 68281.69 68522.97
68912.58 68572.41 .986
320 114745.56 113869.64 114474.62 114363.27 114137.73 114137.73
114137.73 114137.73 .998
640 164338.98 164338.98 164618.00 164431.98 164130.34 164130.34
164130.34 164130.34 .998
1280 209473.40 209134.54 209473.40 209360.44 210040.62 210040.62
210097.51 210059.58 1.003
2560 242703.38 242627.46 242779.34 242703.39 244001.26 243847.85
243732.91 243860.67 1.004
As you can see, the load collapsed at the high load end with stock
scheduler knobs (desktop latency). With knobs set to scale, the delta
disappeared.
I thought perhaps the bogus (shouldn't exist) CPU domain in mainline
somehow contributes to the strange behavioral delta, but killing it made
zero difference. All of these numbers for both trees were logged with
the below applies, but as noted, it changed nothing.
From: Alex Shi
Date: Mon, 17 Dec 2012 09:42:57 +0800
Subject: [PATCH 01/18] sched: remove SD_PERFER_SIBLING flag
The flag was introduced in commit b5d978e0c7e79a. Its purpose seems
trying to fullfill one node first in NUMA machine via pulling tasks
from other nodes when the node has capacity.
Its advantage is when few tasks share memories among them, pulling
together is helpful on locality, so has performance gain. The shortage
is it will keep unnecessary task migrations thrashing among different
nodes, that reduces the performance gain, and just hurt performance if
tasks has no memory cross.
Thinking about the sched numa balancing patch is coming. The small
advantage are meaningless to us, So better to remove this flag.
Reported-by: Mike Galbraith
Signed-off-by: Alex Shi
---
include/linux/sched.h| 1 -
include/linux/topology.h | 2 --
kernel/sched/core.c | 1 -
kernel/sched/fair.c | 19 +--
4 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5dafac3..6dca96c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -836,7 +836,6 @@ enum cpu_idle_type {
#define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg
resources */
#define SD_SERIALIZE 0x0400 /* Only a single load balancing
instance */
#define SD_ASYM_PACKING0x0800 /* Place busy groups earlier in
the domain */
-#define SD_PREFER_SIBLING 0x1000 /* Prefer to place tasks in a sibling
domain */
#define SD_OVERLAP 0x2000 /* sched_domains of this level
Re: [PATCH] dw_dmac: print out DW_PARAMS and DWC_PARAMS when debug
On Fri, Jan 18, 2013 at 8:40 PM, Andy Shevchenko wrote: > It's usefull to have the values of the DW_PARAMS and DWC_PARAMS printed when > debug mode is enabled. > > Signed-off-by: Andy Shevchenko Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: move soft LLP code from tasklet to dwc_scan_descriptors
On Fri, Jan 18, 2013 at 5:44 PM, Andy Shevchenko wrote: > The proper place for the main logic of the soft LLP mode is > dwc_scan_descriptors. It prevents to get the transfer unexpectedly aborted in > case the user calls dwc_tx_status. > > Signed-off-by: Andy Shevchenko Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
Yeah, thanks Alex. :) So this is a non power sequence version of backlight & panel enabling, isn't it? I remember we talked about this several days ago and you mentioned kernel guys want an ad-hoc version(power sequence logics inside driver, not in DT) and I believe this is it, right? I think finally I can enable Tegra30 cardhu's display after this patch merged. Mark On 01/19/2013 06:30 PM, Alexandre Courbot wrote: > This series introduces a way to use pwm-backlight hooks with platforms > that use the device tree through a subdriver system. It also adds support > for the Tegra-based Ventana board, adding the last missing block to enable > its panel. Support for other Tegra board can thus be easily added. > > I have something else in mind to properly support this (power > sequences), but this work relies on the GPIO subsystem redesign which will > take some time. The pwm-backlight subdrivers can do the job by the meantime. > > There are a few design points that might need to be discussed: > 1) Link order is important: subdrivers register themselves in their > module_init function, which must be called before pwm-backlight's probe. > This forbids linking subdrivers as separate modules from pwm-backlight. > 2) The subdriver's data is temporarily passed through the backlight > device's driver data. This should not hurt, but maybe there is a better way > to do this. > 3) Subdrivers must add themselves into pwm-backlight's own of_device_id > table. It would be cleaner to not have to list subdrivers into > pwm-backlight's main file, but I cannot think of a way to do otherwise. > > Suggestions for the 3 points listed above are very welcome - in any case, > I hope to make this converge into something mergeable quickly. > > Note that these patches are the last missing block to get a functional > panel on Tegra boards. Using 3.8rc4 and these patches, the internal panel > on Ventana is usable out-of-the-box. Yay. > > Alexandre Courbot (3): > pwm-backlight: add subdriver mechanism > tegra: pwm-backlight: add tegra pwm-bl driver > tegra: ventana: of: add host1x device to DT > > arch/arm/boot/dts/tegra20-ventana.dts | 29 +- > arch/arm/configs/tegra_defconfig | 1 + > drivers/video/backlight/Kconfig| 7 ++ > drivers/video/backlight/Makefile | 4 + > drivers/video/backlight/pwm_bl.c | 70 ++- > drivers/video/backlight/pwm_bl_tegra.c | 159 > + > include/linux/pwm_backlight.h | 15 > 7 files changed, 281 insertions(+), 4 deletions(-) > create mode 100644 drivers/video/backlight/pwm_bl_tegra.c > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit
On Sat, Jan 19, 2013 at 06:38:08AM +, Al Viro wrote:
> > [ 64.313636] kbd[2563]: segfault at 9fe ip 09fe sp b758293c
> > error 4 in dash[8048000+18000]
> >
> > After bisecting, the following commit seems responsible:
> > 1d4b4b2994b5fc208963c0b795291f8c1f18becf (x86, um: switch to generic
> > fork/vfork/clone)
>
> Er... Bisect of the guest kernel, I take it? Could you check if building
> the guest !SMP affects anything?
OK... I think I understand what's going on. We need asmlinkage_protect
in sys_clone() ;-/ For what it's worth, I really wonder if we ought to
treat that as syscall wrappers - i.e. have SYSCALL_DEFINEx on i386 add
a wrapper that would do asmlinkage_protect itself. IMO it's the same kind
of thing as argument normalization handled by syscall wrappers - we make
sure that C function plays well with what asm glue is doing and expecting.
Anyway, the following seems to fix the problem here (and yes, I could reproduce
it with your config); could you verify that it fixes things on your setup?
If it does, this sucker should go into mainline and -stable...
diff --git a/kernel/fork.c b/kernel/fork.c
index a31b823..e05cff2 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1660,8 +1660,10 @@ SYSCALL_DEFINE5(clone, unsigned long, clone_flags,
unsigned long, newsp,
int, tls_val)
#endif
{
- return do_fork(clone_flags, newsp, 0,
- parent_tidptr, child_tidptr);
+ long ret = do_fork(clone_flags, newsp, 0, parent_tidptr, child_tidptr);
+ asmlinkage_protect(5, ret, clone_flags, newsp,
+ parent_tidptr, child_tidptr, tls_val);
+ return ret;
}
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Fix audio on Nokia RX-51
This patch series updating rx51 sound driver, using snd_soc_register_card, adding module alias for autoloading kernel driver and registring sound driver in rx51 board code. Pali Rohár (2): ASoC: omap: rx51: Use snd_soc_register_card and add module alias for autoloading driver ARM: OMAP: rx51: Register audio device arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++ sound/soc/omap/rx51.c| 50 +++--- 2 files changed, 41 insertions(+), 20 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: OMAP: rx51: Register audio device
Signed-off-by: Pali Rohár
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 45d401a..038ea1f 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1370,6 +1370,16 @@ error:
*/
}
+static struct platform_device rx51_audio_device = {
+ .name = "rx51-audio",
+ .id = -1,
+};
+
+static void __init rx51_init_audio(void)
+{
+ platform_device_register(_audio_device);
+}
+
static struct tsc2005_platform_data tsc2005_pdata = {
.ts_pressure_max= 2048,
.ts_pressure_fudge = 2,
@@ -1568,6 +1578,7 @@ void __init rx51_peripherals_init(void)
gpmc_onenand_init(board_onenand_data);
board_smc91x_init();
rx51_add_gpio_keys();
+ rx51_init_audio();
rx51_init_wl1251();
rx51_init_tsc2005();
rx51_init_si4713();
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ASoC: omap: rx51: Use snd_soc_register_card and add module alias for autoloading driver
Signed-off-by: Pali Rohár
---
sound/soc/omap/rx51.c | 50 +
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/sound/soc/omap/rx51.c b/sound/soc/omap/rx51.c
index d921ddb..82e3aae 100644
--- a/sound/soc/omap/rx51.c
+++ b/sound/soc/omap/rx51.c
@@ -391,10 +391,9 @@ static struct snd_soc_card rx51_sound_card = {
.num_configs = ARRAY_SIZE(rx51_codec_conf),
};
-static struct platform_device *rx51_snd_device;
-
-static int __init rx51_soc_init(void)
+static int rx51_soc_probe(struct platform_device *pdev)
{
+ struct snd_soc_card *card = _sound_card;
int err;
if (!machine_is_nokia_rx51())
@@ -409,22 +408,18 @@ static int __init rx51_soc_init(void)
if (err)
goto err_gpio_eci_sw;
- rx51_snd_device = platform_device_alloc("soc-audio", -1);
- if (!rx51_snd_device) {
- err = -ENOMEM;
- goto err1;
- }
-
- platform_set_drvdata(rx51_snd_device, _sound_card);
+ card->dev = >dev;
- err = platform_device_add(rx51_snd_device);
- if (err)
- goto err2;
+ err = snd_soc_register_card(card);
+ if (err) {
+ dev_err(>dev, "snd_soc_register_card failed (%d)\n", err);
+ goto err_snd;
+ }
return 0;
-err2:
- platform_device_put(rx51_snd_device);
-err1:
+
+err_snd:
+ card->dev = NULL;
gpio_free(RX51_ECI_SW_GPIO);
err_gpio_eci_sw:
gpio_free(RX51_TVOUT_SEL_GPIO);
@@ -433,19 +428,34 @@ err_gpio_tvout_sel:
return err;
}
-static void __exit rx51_soc_exit(void)
+static int rx51_soc_remove(struct platform_device *pdev)
{
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+
snd_soc_jack_free_gpios(_av_jack, ARRAY_SIZE(rx51_av_jack_gpios),
rx51_av_jack_gpios);
- platform_device_unregister(rx51_snd_device);
+ snd_soc_unregister_card(card);
+ card->dev = NULL;
+
gpio_free(RX51_ECI_SW_GPIO);
gpio_free(RX51_TVOUT_SEL_GPIO);
+
+ return 0;
}
-module_init(rx51_soc_init);
-module_exit(rx51_soc_exit);
+static struct platform_driver rx51_soc_driver = {
+ .driver = {
+ .name = "rx51-audio",
+ .owner = THIS_MODULE,
+ },
+ .probe = rx51_soc_probe,
+ .remove = rx51_soc_remove,
+};
+
+module_platform_driver(rx51_soc_driver);
MODULE_AUTHOR("Nokia Corporation");
MODULE_DESCRIPTION("ALSA SoC Nokia RX-51");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:rx51-audio");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RX-51: Add leds lp5523 names from Maemo 5 2.6.28 kernel
Signed-off-by: Pali Rohár
---
arch/arm/mach-omap2/board-rx51-peripherals.c |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 7611958..9a0dbb7 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -168,30 +168,39 @@ static struct tsl2563_platform_data
rx51_tsl2563_platform_data = {
#if defined(CONFIG_LEDS_LP5523) || defined(CONFIG_LEDS_LP5523_MODULE)
static struct lp5523_led_config rx51_lp5523_led_config[] = {
{
+ .name = "lp5523:kb1",
.chan_nr= 0,
.led_current= 50,
}, {
+ .name = "lp5523:kb2",
.chan_nr= 1,
.led_current= 50,
}, {
+ .name = "lp5523:kb3",
.chan_nr= 2,
.led_current= 50,
}, {
+ .name = "lp5523:kb4",
.chan_nr= 3,
.led_current= 50,
}, {
+ .name = "lp5523:b",
.chan_nr= 4,
.led_current= 50,
}, {
+ .name = "lp5523:g",
.chan_nr= 5,
.led_current= 50,
}, {
+ .name = "lp5523:r",
.chan_nr= 6,
.led_current= 50,
}, {
+ .name = "lp5523:kb5",
.chan_nr= 7,
.led_current= 50,
}, {
+ .name = "lp5523:kb6",
.chan_nr= 8,
.led_current= 50,
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia
Signed-off-by: Pali Rohár
---
drivers/usb/gadget/nokia.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/usb/gadget/nokia.c b/drivers/usb/gadget/nokia.c
index 661600a..56409ee 100644
--- a/drivers/usb/gadget/nokia.c
+++ b/drivers/usb/gadget/nokia.c
@@ -38,6 +38,7 @@
* a "gcc --combine ... part1.c part2.c part3.c ... " build would.
*/
#include "u_serial.c"
+#include "f_mass_storage.c"
#include "f_acm.c"
#include "f_ecm.c"
#include "f_obex.c"
@@ -99,6 +100,17 @@ MODULE_LICENSE("GPL");
/*-*/
+static struct fsg_module_parameters fsg_mod_data = {
+ .stall = 0,
+ .luns = 2,
+ .removable_count = 2,
+ .removable = { 1, 1, },
+};
+
+FSG_MODULE_PARAMETERS(/* no prefix */, fsg_mod_data);
+
+static struct fsg_common fsg_common;
+
static u8 hostaddr[ETH_ALEN];
static int __init nokia_bind_config(struct usb_configuration *c)
@@ -125,6 +137,11 @@ static int __init nokia_bind_config(struct
usb_configuration *c)
if (status)
printk(KERN_DEBUG "could not bind ecm config\n");
+ status = fsg_bind_config(c->cdev, c, _common);
+ if (status)
+ printk(KERN_DEBUG "could not bind fsg config\n");
+ fsg_common_put(_common);
+
return status;
}
@@ -148,6 +165,8 @@ static int __init nokia_bind(struct usb_composite_dev *cdev)
{
struct usb_gadget *gadget = cdev->gadget;
int status;
+ void*retp;
+ struct fsg_config fsg_cfg;
status = gphonet_setup(cdev->gadget);
if (status < 0)
@@ -161,6 +180,15 @@ static int __init nokia_bind(struct usb_composite_dev
*cdev)
if (status < 0)
goto err_ether;
+ fsg_config_from_params(_cfg, _mod_data);
+ fsg_cfg.vendor_name = "Nokia";
+ fsg_cfg.product_name = "N900";
+ retp = fsg_common_init(_common, cdev, _cfg);
+ if (IS_ERR(retp)) {
+ status = PTR_ERR(retp);
+ goto err_fsg;
+ }
+
status = usb_string_ids_tab(cdev, strings_dev);
if (status < 0)
goto err_usb;
@@ -190,6 +218,8 @@ static int __init nokia_bind(struct usb_composite_dev *cdev)
return 0;
err_usb:
+ fsg_common_put(_common);
+err_fsg:
gether_cleanup();
err_ether:
gserial_cleanup();
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RX-51: Register twl4030-madc device
Signed-off-by: Pali Rohár
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9a0dbb7..286292e 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1364,6 +1364,16 @@ static void __init rx51_init_lirc(void)
}
#endif
+static struct platform_device madc_hwmon = {
+ .name = "twl4030_madc_hwmon",
+ .id = -1,
+};
+
+static void __init rx51_init_twl4030_hwmon(void)
+{
+ platform_device_register(_hwmon);
+}
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1386,5 +1396,6 @@ void __init rx51_peripherals_init(void)
omap_hsmmc_init(mmc);
rx51_charger_init();
+ rx51_init_twl4030_hwmon();
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.7.3, ttyUSB0 serial problem - devices stop working and only reboot helps (Inappropriate ioctl for device)
Arkadiusz Miskiewicz wrote: On Saturday 19 of January 2013, Arkadiusz Miskiewicz wrote: On Saturday 19 of January 2013, Greg Kroah-Hartman wrote: On Fri, Jan 18, 2013 at 11:28:43PM +0100, Arkadiusz Miskiewicz wrote: Hi. Using 3.7.3 kernel and connecting two rs232 usb adapters, CP2102 and FT232RL, one after disconnecting another. After few cycles of reconnecting and using socat (below) I'm getting problems accessing ttyUSB0: ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffb70c6ae0) = -1 ENOTTY (Inappropriate ioctl for device) Unloading and reloading (by udev) modules ftdio_sio, cp210x, usbserial doesn't help. I have to reboot to get ttyUSB0 working (regardless of which driver, ftdio_sio or cp210x is handling ttyUSB0 - both stop working). Any clues? The kernel log shows the device getting removed a bunch and then coming back, which implies electrical issues (flaky connection, low power, etc.) Are you really removing it and plugging it back in? Or is it doing it all by itself? I was doing plug in CP2102, remove it, plug in FT232RL after few seconds, remove it, plug in CP... (and various variations, several times) and testing with socat before removing devices. After some iteration the problem appears and only reboot helps. The issue is really weird. Machine is Thinkpad T400 2764CTO (latest bios). When the problem happened on 3.7.3 today I rebooted into 3.8rc4 and ... freshly after reboot and plugging in PL2303 adapter the problem was already there. Didn't have to do unplug/plug cycle to make it happen. Looks like sometimes reboot cures the problem, sometimes it doesn't. Now powered off laptop and powered it on - problem gone. Connected PL2303, ran socat, disconnected PL2303 (while socat was running) -> problem happened again. Looks like it doesn't depend on adapter chip type. So to reproduce here: - boot fresh 3.8rc4 - plug in some adapter (PL2303 for example) - run "socat -ddd -s -u /dev/ttyUSB0,raw,echo=0,b115200,crnl,noctty,nonblock - | logger" - it should run fine, without any error - disconnect adapter; socat should exit with error "W cannot restore terminal settings on fd 3: Input/output error" - plug in adapter again - run socat again -> this time error "E tcgetattr(3, 0x7fff21411780): Inappropriate ioctl for device" immediately always; regardless which adapter is used and if kernel module drivers for these adapters were reloaded dmesg: http://pastebin.com/r1Q5mmgt config: http://pastebin.com/8dpFFzuU lspci: http://pastebin.com/TBtUg1tW lsusb: http://pastebin.com/SueVw9CD [ 53.776047] usb 4-1: new full-speed USB device number 2 using uhci_hcd [ 53.938053] usb 4-1: New USB device found, idVendor=067b, idProduct=2303 [ 53.938060] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 53.938065] usb 4-1: Product: USB-Serial Controller [ 53.938068] usb 4-1: Manufacturer: Prolific Technology Inc. [ 53.949924] usbcore: registered new interface driver usbserial [ 53.950364] usbcore: registered new interface driver usbserial_generic [ 53.951147] usbserial: USB Serial support registered for generic [ 53.954268] usbcore: registered new interface driver pl2303 [ 53.955009] usbserial: USB Serial support registered for pl2303 [ 53.955039] pl2303 4-1:1.0: pl2303 converter detected [ 53.967394] usb 4-1: pl2303 converter now attached to ttyUSB0 [ 64.492122] usb 4-1: USB disconnect, device number 2 [ 64.501748] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 [ 64.502343] pl2303 4-1:1.0: device disconnected [ 66.494930] usb 4-1: new full-speed USB device number 3 using uhci_hcd [ 66.654247] usb 4-1: New USB device found, idVendor=067b, idProduct=2303 [ 66.654261] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 66.654269] usb 4-1: Product: USB-Serial Controller [ 66.654276] usb 4-1: Manufacturer: Prolific Technology Inc. [ 66.659661] pl2303 4-1:1.0: pl2303 converter detected [ 66.671587] usb 4-1: pl2303 converter now attached to ttyUSB0 5722 munmap(0x7f1bfc0d7000, 4096) = 0 5722 write(2, "2013/01/19 09:36:38 socat[5722] E tcgetattr(3, 0x7fffeff64020): Inappropriate ioctl for device\n", 95) = 95 5722 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffeff63e50) = -1 ENOTTY (Inappropriate ioctl for device) 5722 write(2, "2013/01/19 09:36:38 socat[5722] E tcgetattr(3, 0x7fffeff63f90): Inappropriate ioctl for device\n", 95) = 95 5722 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffeff63ec0) = -1 ENOTTY (Inappropriate ioctl for device) 5722 write(2, "2013/01/19 09:36:38 socat[5722] E tcgetattr(3, 0x7fffeff64160): Inappropriate ioctl for device\n", 95) = 95 5722 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 5722 ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffeff64330) = -1 ENOTTY (Inappropriate ioctl for device) 5722 select(4, [3], [1], [], NULL) = 2 (in [3], out [1]) If I unplug the
Re: [PATCH] power: bq27x00_battery: Export all battery registers via sysfs
On Sat, Jan 19, 2013 at 03:01:43PM +0100, Pali Rohár wrote:
> bq27xxx batteries have a lot of properties, more than power_supply interface.
> Some of them can be usefull for userspace applications (like CI bit) but
> does not make sense to add bq specified property to power_supply interface.
> When bq27x00_battery is not loaded userspace application (like i2cget) can
> use /dev/i2c-* interface for raw access. But when kernel module is attached
> to i2c device, userspace applications cannot access it via /dev/i2c-*.
> Also it is not usefull for userspace to unload module before reading values
> form /dev/i2c-* and then load it again.
If it is useful for userspace applications, you probably do want to
make a proper interface for it? What is "CI" bit?
We were discussing it before, right?
http://permalink.gmane.org/gmane.linux.kernel/1220570
I said:
In any case, I just think that being able to access already bound
I2C devices from userspace might be a good thing for debugging,
but having such an interface per-driver is impractical.
So, I still think that making a generic interface is the way to go.
And Mark Brown said:
if this is a device that has registers that fit within regmap then the
regmap API provides a debugfs interface for dumping the register map as
standard.
...
The regmap debug file is a file of lines in the format 'regnum: value'
where both fields have a fixed width so should be easily parsable.
So, it seems that we have that interface already.
Here is the whole discussion:
http://comments.gmane.org/gmane.linux.kernel/1209421
Thanks,
> This patch exporting all battery registers to sysfs entry "registers" in
> battery power_supply directory. Format is "register=value" on separate line.
> Because length of registers are different for each bq battery more for loops
> are needed.
>
> Signed-off-by: Pali Rohár
> ---
> drivers/power/bq27x00_battery.c | 98
> +--
> 1 file changed, 95 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c
> index 7087d0d..af0f68f 100644
> --- a/drivers/power/bq27x00_battery.c
> +++ b/drivers/power/bq27x00_battery.c
> @@ -690,6 +690,90 @@ static void bq27x00_external_power_changed(struct
> power_supply *psy)
> schedule_delayed_work(>work, 0);
> }
>
> +/* code for register device access via sysfs */
> +
> +static ssize_t bq27x00_battery_sysfs_print_reg(struct bq27x00_device_info
> *di,
> + u8 reg, bool single, char *buf)
> +{
> + int ret = bq27x00_read(di, reg, single);
> + if (ret < 0)
> + return sprintf(buf, "%#.2x=error %d\n", reg, ret);
> + else
> + return sprintf(buf, "%#.2x=%#.2x\n", reg, ret);
> +}
> +
> +static ssize_t bq27x00_battery_sysfs_show_registers(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct power_supply *psy = dev_get_drvdata(dev);
> + struct bq27x00_device_info *di = container_of(psy,
> + struct bq27x00_device_info,
> + bat);
> + u8 reg;
> + ssize_t ret = 0;
> +
> + switch (di->chip) {
> +
> + case BQ27000:
> + for (reg=0x00; reg<=0x01; reg+=1)
> + ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
> buf+ret);
> + for (reg=0x02; reg<=0x08; reg+=2)
> + ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
> buf+ret);
> + for (reg=0x0A; reg<=0x0B; reg+=1)
> + ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
> buf+ret);
> + for (reg=0x0C; reg<=0x2A; reg+=2)
> + ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
> buf+ret);
> + for (reg=0x2C; reg<=0x7F; reg+=1)
> + ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
> buf+ret);
> + break;
> +
> + case BQ27500:
> + for (reg=0x00; reg<=0x2C; reg+=2)
> + ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
> buf+ret);
> + for (reg=0x2E; reg<=0x3B; reg+=1)
> + ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
> buf+ret);
> + for (reg=0x3C; reg<=0x3C; reg+=2)
> + ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
> buf+ret);
> + for (reg=0x3E; reg<=0x7F; reg+=1)
> + ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
> buf+ret);
> + break;
> +
> + case BQ27425:
> + for (reg=0x00; reg<=0x3C; reg+=2)
> + ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
> buf+ret);
> + for (reg=0x3E; reg<=0x7F; reg+=1)
> + ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
> buf+ret);
> + break;
> +
> + }
> +
> +
kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware when compiling under Fedora 18
I am having this strange issue. My computer has a LCD display that does not send any EDID, and therefore I need the command parameter "drm_kms_helper.edid_firmware=edid/1280x1024.bin" In Fedora 16, the stock kernel does not have CONFIG_DRM_LOAD_EDID_FIRMWARE set. Therefore I compiled my own kernel from vanilla sources, and the parameter worked. I have just now upgraded to Fedora 18. The new stock kernel is supposed to have CONFIG_DRM_LOAD_EDID_FIRMWARE set, but when I boot with the drm_kms_helper parameter, I get a message "drm_kms_helper: Unknown parameter `bin'". I thought this was a kernel bug caused by some patch in the stock kernel, so I filed https://bugzilla.redhat.com/show_bug.cgi?id=901899 , and then proceeded to compile 3.8-rc4 from vanilla sources. However, I am surprised to find that the vanilla sources, when compiled under Fedora 18, exhibit the same bug. Has anyone seen a situation like this? Is this a possible compiler bug in Fedora 18? A grub2 bug? Apparently the kernel is misparsing the commandline parameter and thinks "bin" is the module parameter, not "edid_firmware". [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.8.0-rc4 (a...@karlalex.palosanto.com) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #19 SMP PREEMPT Sat Jan 19 18:47:11 ECT 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.8.0-rc4 root=UUID=34116aa2-ba9e-47a6-9371-9342830b4820 ro rd.md=0 rd.lvm=0 rd.dm=0 vconsole.keymap=es rd.luks=0 rhgb quiet zcache memmap=768M@4G LANG=es_ES.UTF-8 drm_kms_helper.edid_firmware=edid/1280x1024.bin [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009f3ff] usable [0.00] BIOS-e820: [mem 0x0009f400-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcf58] usable [0.00] BIOS-e820: [mem 0xcf59-0xcf5e2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf5e3000-0xcf5e] ACPI data [0.00] BIOS-e820: [mem 0xcf5f-0xcf5f] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] e820: user-defined physical RAM map: [0.00] user: [mem 0x-0x0009f3ff] usable [0.00] user: [mem 0x0009f400-0x0009] reserved [0.00] user: [mem 0x000f-0x000f] reserved [0.00] user: [mem 0x0010-0xcf58] usable [0.00] user: [mem 0xcf59-0xcf5e2fff] ACPI NVS [0.00] user: [mem 0xcf5e3000-0xcf5e] ACPI data [0.00] user: [mem 0xcf5f-0xcf5f] reserved [0.00] user: [mem 0xe000-0xefff] reserved [0.00] user: [mem 0xfec0-0x] reserved [0.00] user: [mem 0x0001-0x00012fff] usable [0.00] SMBIOS 2.5 present. [0.00] DMI: OEM OEM/G31MVP, BIOS 6.00 PG 09/11/2008 [0.00] e820: update [mem 0x-0x] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x13 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-F7FFF uncachable [0.00] F8000-FBFFF write-through [0.00] FC000-F uncachable [0.00] MTRR variable ranges enabled: [0.00] 0 base 1 mask FE000 write-back [0.00] 1 base 12000 mask FF000 write-back [0.00] 2 base 0 mask F8000 write-back [0.00] 3 base 08000 mask FC000 write-back [0.00] 4 base 0C000 mask FF000 write-back [0.00] 5 base 0CF70 mask 0 uncachable [0.00] 6 base 0CF80 mask FFF80 uncachable [0.00] 7 base 0CF60 mask 0 uncachable [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] original variable MTRRs [0.00] reg 0, base: 4GB, range: 512MB, type WB [0.00] reg 1, base: 4608MB, range: 256MB, type WB [0.00] reg 2, base: 0GB, range: 2GB, type WB [0.00] reg 3, base: 2GB, range: 1GB, type WB [0.00] reg 4, base: 3GB, range: 256MB, type WB [0.00] reg 5, base: 3319MB, range: 1MB, type UC [0.00] reg 6, base: 3320MB, range: 8MB, type UC [0.00] reg 7, base: 3318MB, range: 1MB, type UC [0.00] total RAM covered: 4086M [0.00] Found optimal
Re: jbd2: don't wake kjournald unnecessarily
On Sun, Jan 20, 2013 at 1:35 AM, Sedat Dilek wrote: > On Sun, Jan 20, 2013 at 1:06 AM, Sedat Dilek wrote: >> On Sun, Jan 20, 2013 at 12:44 AM, Sedat Dilek wrote: >>> Hi, >>> >>> I and some others hit a similiar problem in Linux-Next >>> (next-20130118), please see [1] and [2]. >>> >>> [3] has a interim analyze of my problems. >>> >>> After suspecting the problem was caused by TTY-NEXT, it turned out to >>> be a JBD2 problem finally. >>> The freezer/pm_test was helpful to hit the issue (Thanks Rafael for the >>> hint!). >>> >>> So, the issue has two faces: TTY and JBD2. >>> [4] gives a list and URLs of the patches I had to apply to have a >>> clean system again. >>> >>> After applying the two TTY patches (without Eric's JBD2-fix!) the >>> call-trace after freezer/pm_test looked like this; >>> >>> [ 433.527986] PM: Syncing filesystems ... done. >>> [ 433.843761] PM: Preparing system for mem sleep >>> [ 436.306002] Freezing user space processes ... >>> [ 456.304956] Freezing of tasks failed after 20.01 seconds (1 tasks >>> refusing to freeze, wq_busy=0): >>> [ 456.305060] Cache I/O D 8180d780 0 2132 1 >>> 0x0004 >>> [ 456.305065] 88007b9dfe18 0046 88007b9dfdc8 >>> 00030001 >>> [ 456.305069] 880097e21720 88007b9dffd8 88007b9dffd8 >>> 88007b9dffd8 >>> [ 456.305072] 880119b32e40 880097e21720 88007b9dfe28 >>> 880118077800 >>> [ 456.305076] Call Trace: >>> [ 456.305085] [] schedule+0x29/0x70 >>> [ 456.305089] [] jbd2_log_wait_commit+0xcd/0x1a0 >>> [ 456.305094] [] ? add_wait_queue+0x60/0x60 >>> [ 456.305098] [] ext4_sync_file+0x205/0x380 >>> [ 456.305103] [] do_fsync+0x5d/0x90 >>> [ 456.305108] [] ? sys_write+0x6b/0xa0 >>> [ 456.305111] [] sys_fsync+0x10/0x20 >>> [ 456.305114] [] system_call_fastpath+0x1a/0x1f >>> [ 456.305122] >>> [ 456.305124] Restarting tasks ... done. >>> [ 456.315056] video LNXVIDEO:00: Restoring backlight state >>> >>> After applying Eric's patch [5], I could not hit the call-trace again. >>> NOTE: The patch is from December 2012 and is not shipped in latest >>> Linux-Next. >>> >>> The attached testcase script was helpful to force the call-trace. >>> I have run 50 loops of it w/o an issue! >>> >>> Feel free to add a Reported-by/Tested-by. >>> ( The issue kept me busy for the last days. ) >>> >>> Regards, >>> - Sedat - >>> >>> [1] http://marc.info/?t=13528366462=1=2 >>> [2] http://marc.info/?t=13586202374=1=2 >>> [3] http://marc.info/?l=linux-kernel=135862010419101=2 >>> [4] http://marc.info/?l=linux-next=135863550923093=2 >>> [5] http://patchwork.ozlabs.org/patch/207237/ >> >> Hi all, >> >> this is really ugly... I could cry! >> >> GRRR, I have hit the original issue again while running my testcase script! >> >> [ 363.831226] PM: Syncing filesystems ... done. >> [ 363.988855] PM: Preparing system for mem sleep >> [ 369.032965] Freezing user space processes ... (elapsed 0.11 seconds) done. >> [ 369.145792] Freezing remaining freezable tasks ... >> [ 389.137643] Freezing of tasks failed after 20.01 seconds (1 tasks >> refusing to freeze, wq_busy=0): >> [ 389.137760] jbd2/loop0-8D 8180d780 0 295 2 >> 0x >> [ 389.137769] 8801181dfb68 0046 880117de5c80 >> 0001 >> [ 389.137778] 880117de5c80 8801181dffd8 8801181dffd8 >> 8801181dffd8 >> [ 389.137784] 81c15440 880117de5c80 8801181dfb68 >> 88011fa14738 >> [ 389.137791] Call Trace: >> [ 389.137810] [] ? __wait_on_buffer+0x30/0x30 >> [ 389.137819] [] schedule+0x29/0x70 >> [ 389.137825] [] io_schedule+0x8f/0xd0 >> [ 389.137832] [] sleep_on_buffer+0xe/0x20 >> [ 389.137842] [] __wait_on_bit+0x5f/0x90 >> [ 389.137849] [] ? submit_bh+0x121/0x1e0 >> [ 389.137856] [] ? __wait_on_buffer+0x30/0x30 >> [ 389.137864] [] out_of_line_wait_on_bit+0x7c/0x90 >> [ 389.137873] [] ? autoremove_wake_function+0x40/0x40 >> [ 389.137879] [] __wait_on_buffer+0x2e/0x30 >> [ 389.137891] [] >> jbd2_journal_commit_transaction+0x18cc/0x1d60 >> [ 389.137899] [] ? _raw_spin_lock_irqsave+0x2e/0x40 >> [ 389.137908] [] ? try_to_del_timer_sync+0x4f/0x70 >> [ 389.137915] [] kjournald2+0xd6/0x3e0 >> [ 389.137921] [] ? add_wait_queue+0x60/0x60 >> [ 389.137926] [] ? commit_timeout+0x10/0x10 >> [ 389.137932] [] kthread+0xc0/0xd0 >> [ 389.137939] [] ? flush_kthread_worker+0xb0/0xb0 >> [ 389.137946] [] ret_from_fork+0x7c/0xb0 >> [ 389.137951] [] ? flush_kthread_worker+0xb0/0xb0 >> [ 389.138017] >> [ 389.138021] Restarting kernel threads ... done. >> [ 389.138173] Restarting tasks ... done. >> [ 389.147980] video LNXVIDEO:00: Restoring backlight state >> >> I suspect there are still issues in JBD2 (BTW I run here EXT4FS). >> >> [ 389.137643] Freezing of tasks failed after 20.01 seconds (1 tasks >> refusing to freeze, wq_busy=0): >> [ 389.137760] jbd2/loop0-8D 8180d780 0 295 2 >>
Re: jbd2: don't wake kjournald unnecessarily
On Sun, Jan 20, 2013 at 1:06 AM, Sedat Dilek wrote: > On Sun, Jan 20, 2013 at 12:44 AM, Sedat Dilek wrote: >> Hi, >> >> I and some others hit a similiar problem in Linux-Next >> (next-20130118), please see [1] and [2]. >> >> [3] has a interim analyze of my problems. >> >> After suspecting the problem was caused by TTY-NEXT, it turned out to >> be a JBD2 problem finally. >> The freezer/pm_test was helpful to hit the issue (Thanks Rafael for the >> hint!). >> >> So, the issue has two faces: TTY and JBD2. >> [4] gives a list and URLs of the patches I had to apply to have a >> clean system again. >> >> After applying the two TTY patches (without Eric's JBD2-fix!) the >> call-trace after freezer/pm_test looked like this; >> >> [ 433.527986] PM: Syncing filesystems ... done. >> [ 433.843761] PM: Preparing system for mem sleep >> [ 436.306002] Freezing user space processes ... >> [ 456.304956] Freezing of tasks failed after 20.01 seconds (1 tasks >> refusing to freeze, wq_busy=0): >> [ 456.305060] Cache I/O D 8180d780 0 2132 1 >> 0x0004 >> [ 456.305065] 88007b9dfe18 0046 88007b9dfdc8 >> 00030001 >> [ 456.305069] 880097e21720 88007b9dffd8 88007b9dffd8 >> 88007b9dffd8 >> [ 456.305072] 880119b32e40 880097e21720 88007b9dfe28 >> 880118077800 >> [ 456.305076] Call Trace: >> [ 456.305085] [] schedule+0x29/0x70 >> [ 456.305089] [] jbd2_log_wait_commit+0xcd/0x1a0 >> [ 456.305094] [] ? add_wait_queue+0x60/0x60 >> [ 456.305098] [] ext4_sync_file+0x205/0x380 >> [ 456.305103] [] do_fsync+0x5d/0x90 >> [ 456.305108] [] ? sys_write+0x6b/0xa0 >> [ 456.305111] [] sys_fsync+0x10/0x20 >> [ 456.305114] [] system_call_fastpath+0x1a/0x1f >> [ 456.305122] >> [ 456.305124] Restarting tasks ... done. >> [ 456.315056] video LNXVIDEO:00: Restoring backlight state >> >> After applying Eric's patch [5], I could not hit the call-trace again. >> NOTE: The patch is from December 2012 and is not shipped in latest >> Linux-Next. >> >> The attached testcase script was helpful to force the call-trace. >> I have run 50 loops of it w/o an issue! >> >> Feel free to add a Reported-by/Tested-by. >> ( The issue kept me busy for the last days. ) >> >> Regards, >> - Sedat - >> >> [1] http://marc.info/?t=13528366462=1=2 >> [2] http://marc.info/?t=13586202374=1=2 >> [3] http://marc.info/?l=linux-kernel=135862010419101=2 >> [4] http://marc.info/?l=linux-next=135863550923093=2 >> [5] http://patchwork.ozlabs.org/patch/207237/ > > Hi all, > > this is really ugly... I could cry! > > GRRR, I have hit the original issue again while running my testcase script! > > [ 363.831226] PM: Syncing filesystems ... done. > [ 363.988855] PM: Preparing system for mem sleep > [ 369.032965] Freezing user space processes ... (elapsed 0.11 seconds) done. > [ 369.145792] Freezing remaining freezable tasks ... > [ 389.137643] Freezing of tasks failed after 20.01 seconds (1 tasks > refusing to freeze, wq_busy=0): > [ 389.137760] jbd2/loop0-8D 8180d780 0 295 2 > 0x > [ 389.137769] 8801181dfb68 0046 880117de5c80 > 0001 > [ 389.137778] 880117de5c80 8801181dffd8 8801181dffd8 > 8801181dffd8 > [ 389.137784] 81c15440 880117de5c80 8801181dfb68 > 88011fa14738 > [ 389.137791] Call Trace: > [ 389.137810] [] ? __wait_on_buffer+0x30/0x30 > [ 389.137819] [] schedule+0x29/0x70 > [ 389.137825] [] io_schedule+0x8f/0xd0 > [ 389.137832] [] sleep_on_buffer+0xe/0x20 > [ 389.137842] [] __wait_on_bit+0x5f/0x90 > [ 389.137849] [] ? submit_bh+0x121/0x1e0 > [ 389.137856] [] ? __wait_on_buffer+0x30/0x30 > [ 389.137864] [] out_of_line_wait_on_bit+0x7c/0x90 > [ 389.137873] [] ? autoremove_wake_function+0x40/0x40 > [ 389.137879] [] __wait_on_buffer+0x2e/0x30 > [ 389.137891] [] > jbd2_journal_commit_transaction+0x18cc/0x1d60 > [ 389.137899] [] ? _raw_spin_lock_irqsave+0x2e/0x40 > [ 389.137908] [] ? try_to_del_timer_sync+0x4f/0x70 > [ 389.137915] [] kjournald2+0xd6/0x3e0 > [ 389.137921] [] ? add_wait_queue+0x60/0x60 > [ 389.137926] [] ? commit_timeout+0x10/0x10 > [ 389.137932] [] kthread+0xc0/0xd0 > [ 389.137939] [] ? flush_kthread_worker+0xb0/0xb0 > [ 389.137946] [] ret_from_fork+0x7c/0xb0 > [ 389.137951] [] ? flush_kthread_worker+0xb0/0xb0 > [ 389.138017] > [ 389.138021] Restarting kernel threads ... done. > [ 389.138173] Restarting tasks ... done. > [ 389.147980] video LNXVIDEO:00: Restoring backlight state > > I suspect there are still issues in JBD2 (BTW I run here EXT4FS). > > [ 389.137643] Freezing of tasks failed after 20.01 seconds (1 tasks > refusing to freeze, wq_busy=0): > [ 389.137760] jbd2/loop0-8D 8180d780 0 295 2 > 0x > > Have a good night, /me -> watching TV! > > - Sedat - Man, what a NONSENSE I am telling... The mentioned so-called fix is already in next-20130118, shame on me!
Re: Linux detects only 2.6GiB RAM in legacy boot
On Sat, Jan 19, 2013 at 3:14 PM, richard -rw- weinberger wrote: > BTW: My BIOS is already the latest version. [0.00] raw: [mem 0x-0x0009d7ff] usable [0.00] raw: [mem 0x0009d800-0x0009] reserved [0.00] raw: [mem 0x000e-0x000f] reserved [0.00] raw: [mem 0x0010-0x1fff] usable [0.00] raw: [mem 0x2000-0x201f] reserved [0.00] raw: [mem 0x2020-0x40003fff] usable [0.00] raw: [mem 0x40004000-0x40004fff] reserved [0.00] raw: [mem 0x40005000-0x8cfaafff] usable [0.00] raw: [mem 0x8cfab000-0xdae9efff] reserved [0.00] raw: [mem 0xdae9f000-0xdaf9efff] ACPI NVS [0.00] raw: [mem 0xdaf9f000-0xdaffefff] ACPI data [0.00] raw: [mem 0xdafff000-0xdf9f] reserved [0.00] raw: [mem 0xf800-0xfbff] reserved [0.00] raw: [mem 0xfec0-0xfec00fff] reserved [0.00] raw: [mem 0xfed08000-0xfed08fff] reserved [0.00] raw: [mem 0xfed1-0xfed19fff] reserved [0.00] raw: [mem 0xfed1c000-0xfed1] reserved [0.00] raw: [mem 0xfee0-0xfee00fff] reserved [0.00] raw: [mem 0xffc0-0x] reserved [0.00] raw: [mem 0x0001-0x00011e5f] usable so really it is bios problem. you can request one BIOS update about it or just return it. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/tty/tty_buffer.c:476 flush_to_ldisc()
On Sat, Jan 19, 2013 at 11:44 PM, Sedat Dilek wrote: > Hi Dave, > > I suspected after initial testing a problem in TTY and applied two patches. > After more testing the root cause was a problem in JBD2. > A patch from Eric helped! > Follow the thread in [1] for more details. > > If you are on Linux-Next (next-20130118) you need the following three patches. > > Ilya Zykov (2): > tty: Correct tty buffer flush. > tty: Add driver unthrottle in ioctl(...,TCFLSH,..). > > Eric Sandeen (1): > jbd2: don't wake kjournald unnecessarily > > Hope this helps you. > > Regards, > - Sedat - > > [0] http://marc.info/?t=13586202374=1=2 > [1] http://marc.info/?l=linux-serial=135860500714909=2 > [2] > http://git.kernel.org/?p=linux/kernel/git/gregkh/tty.git;a=commitdiff;h=a1bf9584429d61b7096f93ae09325e1ba538e9e8 > [3] http://patchwork.ozlabs.org/patch/207237/ I am awfully sorry to tell you that my (JBD2) problem still exist! Not sure this is anymore related to TTY-NEXT, so better I shut up! - Sedat - [1] http://marc.info/?l=linux-kernel=135864041624404=2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drivers/crypto/bfin_crc.c: reposition free_irq to avoid access to invalid data
On Mon, Jan 07, 2013 at 11:00:16AM +0100, Julia Lawall wrote:
> From: Julia Lawall
>
> The data referenced by an interrupt handler should not be freed before the
> interrupt is ended. The handler is bfin_crypto_crc_handler. It may refer
> to crc->regs, which is released by the iounmap.
>
> Furthermore, the second argument to all calls to free_irq is incorrect. It
> should be the same as the last argument of request_irq, which is crc,
> rather than crc->dev.
>
> The semantic match that finds the first problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @fn exists@
> expression list es;
> expression a,b;
> identifier f;
> @@
>
> if (...) {
> ... when any
> free_irq(a,b);
> ... when any
> f(es);
> ... when any
> return ...;
> }
>
> @@
> expression list fn.es;
> expression fn.a,fn.b;
> identifier fn.f;
> @@
>
> *f(es);
> ... when any
> *free_irq(a,b);
> //
>
> Signed-off-by: Julia Lawall
Patch applied.
Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: jbd2: don't wake kjournald unnecessarily
On Sun, Jan 20, 2013 at 12:44 AM, Sedat Dilek wrote: > Hi, > > I and some others hit a similiar problem in Linux-Next > (next-20130118), please see [1] and [2]. > > [3] has a interim analyze of my problems. > > After suspecting the problem was caused by TTY-NEXT, it turned out to > be a JBD2 problem finally. > The freezer/pm_test was helpful to hit the issue (Thanks Rafael for the > hint!). > > So, the issue has two faces: TTY and JBD2. > [4] gives a list and URLs of the patches I had to apply to have a > clean system again. > > After applying the two TTY patches (without Eric's JBD2-fix!) the > call-trace after freezer/pm_test looked like this; > > [ 433.527986] PM: Syncing filesystems ... done. > [ 433.843761] PM: Preparing system for mem sleep > [ 436.306002] Freezing user space processes ... > [ 456.304956] Freezing of tasks failed after 20.01 seconds (1 tasks > refusing to freeze, wq_busy=0): > [ 456.305060] Cache I/O D 8180d780 0 2132 1 > 0x0004 > [ 456.305065] 88007b9dfe18 0046 88007b9dfdc8 > 00030001 > [ 456.305069] 880097e21720 88007b9dffd8 88007b9dffd8 > 88007b9dffd8 > [ 456.305072] 880119b32e40 880097e21720 88007b9dfe28 > 880118077800 > [ 456.305076] Call Trace: > [ 456.305085] [] schedule+0x29/0x70 > [ 456.305089] [] jbd2_log_wait_commit+0xcd/0x1a0 > [ 456.305094] [] ? add_wait_queue+0x60/0x60 > [ 456.305098] [] ext4_sync_file+0x205/0x380 > [ 456.305103] [] do_fsync+0x5d/0x90 > [ 456.305108] [] ? sys_write+0x6b/0xa0 > [ 456.305111] [] sys_fsync+0x10/0x20 > [ 456.305114] [] system_call_fastpath+0x1a/0x1f > [ 456.305122] > [ 456.305124] Restarting tasks ... done. > [ 456.315056] video LNXVIDEO:00: Restoring backlight state > > After applying Eric's patch [5], I could not hit the call-trace again. > NOTE: The patch is from December 2012 and is not shipped in latest Linux-Next. > > The attached testcase script was helpful to force the call-trace. > I have run 50 loops of it w/o an issue! > > Feel free to add a Reported-by/Tested-by. > ( The issue kept me busy for the last days. ) > > Regards, > - Sedat - > > [1] http://marc.info/?t=13528366462=1=2 > [2] http://marc.info/?t=13586202374=1=2 > [3] http://marc.info/?l=linux-kernel=135862010419101=2 > [4] http://marc.info/?l=linux-next=135863550923093=2 > [5] http://patchwork.ozlabs.org/patch/207237/ Hi all, this is really ugly... I could cry! GRRR, I have hit the original issue again while running my testcase script! [ 363.831226] PM: Syncing filesystems ... done. [ 363.988855] PM: Preparing system for mem sleep [ 369.032965] Freezing user space processes ... (elapsed 0.11 seconds) done. [ 369.145792] Freezing remaining freezable tasks ... [ 389.137643] Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0): [ 389.137760] jbd2/loop0-8D 8180d780 0 295 2 0x [ 389.137769] 8801181dfb68 0046 880117de5c80 0001 [ 389.137778] 880117de5c80 8801181dffd8 8801181dffd8 8801181dffd8 [ 389.137784] 81c15440 880117de5c80 8801181dfb68 88011fa14738 [ 389.137791] Call Trace: [ 389.137810] [] ? __wait_on_buffer+0x30/0x30 [ 389.137819] [] schedule+0x29/0x70 [ 389.137825] [] io_schedule+0x8f/0xd0 [ 389.137832] [] sleep_on_buffer+0xe/0x20 [ 389.137842] [] __wait_on_bit+0x5f/0x90 [ 389.137849] [] ? submit_bh+0x121/0x1e0 [ 389.137856] [] ? __wait_on_buffer+0x30/0x30 [ 389.137864] [] out_of_line_wait_on_bit+0x7c/0x90 [ 389.137873] [] ? autoremove_wake_function+0x40/0x40 [ 389.137879] [] __wait_on_buffer+0x2e/0x30 [ 389.137891] [] jbd2_journal_commit_transaction+0x18cc/0x1d60 [ 389.137899] [] ? _raw_spin_lock_irqsave+0x2e/0x40 [ 389.137908] [] ? try_to_del_timer_sync+0x4f/0x70 [ 389.137915] [] kjournald2+0xd6/0x3e0 [ 389.137921] [] ? add_wait_queue+0x60/0x60 [ 389.137926] [] ? commit_timeout+0x10/0x10 [ 389.137932] [] kthread+0xc0/0xd0 [ 389.137939] [] ? flush_kthread_worker+0xb0/0xb0 [ 389.137946] [] ret_from_fork+0x7c/0xb0 [ 389.137951] [] ? flush_kthread_worker+0xb0/0xb0 [ 389.138017] [ 389.138021] Restarting kernel threads ... done. [ 389.138173] Restarting tasks ... done. [ 389.147980] video LNXVIDEO:00: Restoring backlight state I suspect there are still issues in JBD2 (BTW I run here EXT4FS). [ 389.137643] Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0): [ 389.137760] jbd2/loop0-8D 8180d780 0 295 2 0x Have a good night, /me -> watching TV! - Sedat - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Negative (setpoint-dirty) in bdi_position_ratio()
In bdi_position_ratio(), get difference (setpoint-dirty) right even when negative. Both setpoint and dirty are unsigned long, the difference was zero-padded thus wrongly sign-extended to s64. This issue affects all 32-bit architectures, does not affect 64-bit architectures where long and s64 are equivalent. In this function, dirty is between freerun and limit, the pseudo-float x is between [-1,1], expected to be negative about half the time. With zero-padding, instead of a small negative x we obtained a large positive one so bdi_position_ratio() returned garbage. Casting the difference to s64 also prevents overflow with left-shift; though normally these numbers are small and I never observed a 32-bit overflow there. (This patch does not solve the PAE OOM issue.) Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia Reported-by: Paul Szabo Reference: http://bugs.debian.org/695182 Signed-off-by: Paul Szabo --- mm/page-writeback.c.old 2012-12-06 22:20:40.0 +1100 +++ mm/page-writeback.c 2013-01-20 07:47:55.0 +1100 @@ -559,7 +559,7 @@ static unsigned long bdi_position_ratio( * => fast response on large errors; small oscillation near setpoint */ setpoint = (freerun + limit) / 2; - x = div_s64((setpoint - dirty) << RATELIMIT_CALC_SHIFT, + x = div_s64(((s64)setpoint - (s64)dirty) << RATELIMIT_CALC_SHIFT, limit - setpoint + 1); pos_ratio = x; pos_ratio = pos_ratio * x >> RATELIMIT_CALC_SHIFT; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: jbd2: don't wake kjournald unnecessarily
Hi, I and some others hit a similiar problem in Linux-Next (next-20130118), please see [1] and [2]. [3] has a interim analyze of my problems. After suspecting the problem was caused by TTY-NEXT, it turned out to be a JBD2 problem finally. The freezer/pm_test was helpful to hit the issue (Thanks Rafael for the hint!). So, the issue has two faces: TTY and JBD2. [4] gives a list and URLs of the patches I had to apply to have a clean system again. After applying the two TTY patches (without Eric's JBD2-fix!) the call-trace after freezer/pm_test looked like this; [ 433.527986] PM: Syncing filesystems ... done. [ 433.843761] PM: Preparing system for mem sleep [ 436.306002] Freezing user space processes ... [ 456.304956] Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0): [ 456.305060] Cache I/O D 8180d780 0 2132 1 0x0004 [ 456.305065] 88007b9dfe18 0046 88007b9dfdc8 00030001 [ 456.305069] 880097e21720 88007b9dffd8 88007b9dffd8 88007b9dffd8 [ 456.305072] 880119b32e40 880097e21720 88007b9dfe28 880118077800 [ 456.305076] Call Trace: [ 456.305085] [] schedule+0x29/0x70 [ 456.305089] [] jbd2_log_wait_commit+0xcd/0x1a0 [ 456.305094] [] ? add_wait_queue+0x60/0x60 [ 456.305098] [] ext4_sync_file+0x205/0x380 [ 456.305103] [] do_fsync+0x5d/0x90 [ 456.305108] [] ? sys_write+0x6b/0xa0 [ 456.305111] [] sys_fsync+0x10/0x20 [ 456.305114] [] system_call_fastpath+0x1a/0x1f [ 456.305122] [ 456.305124] Restarting tasks ... done. [ 456.315056] video LNXVIDEO:00: Restoring backlight state After applying Eric's patch [5], I could not hit the call-trace again. NOTE: The patch is from December 2012 and is not shipped in latest Linux-Next. The attached testcase script was helpful to force the call-trace. I have run 50 loops of it w/o an issue! Feel free to add a Reported-by/Tested-by. ( The issue kept me busy for the last days. ) Regards, - Sedat - [1] http://marc.info/?t=13528366462=1=2 [2] http://marc.info/?t=13586202374=1=2 [3] http://marc.info/?l=linux-kernel=135862010419101=2 [4] http://marc.info/?l=linux-next=135863550923093=2 [5] http://patchwork.ozlabs.org/patch/207237/ run_pm-test_v2.sh Description: Bourne shell script
Re: [PATCH 2/3] signalfd: add ability to return siginfo in a raw format (v2)
Hello Andrey, On Sat, Jan 19, 2013 at 11:50 AM, Andrey Wagin wrote: > 2013/1/19 Michael Kerrisk (man-pages) : >>> As SFD_RAW is being added to the kernel API we should document it. >>> Please keep Michael cc'ed and work with him on getting the manpages >>> updated. >> >> The API is certainly no thing of beauty, as I already remarked here: >> http://thread.gmane.org/gmane.linux.file-systems/70420/focus=1420228 > > All of us have similar thoughts, but we don't know a better solution. > > Here is an example of usage signalfd and pread: > http://lists.openvz.org/pipermail/criu/2013-January/007040.html > >> >> A description of the API can be found here: >> https://lwn.net/Articles/531939/ > > Thanks you for the attempt to involve more people to this discussion. > >> >> The main problem is the ugliness of changing the meaning of pread()'s >> 'offset' argument to be a multiplexed [signal queue selector + queue >> position]. >> >> I do wonder if we can do better, though I have no particular solution >> to offer beyond the sledgehammer of adding a new system call. > > If we are choosing between this interface or a new syscall, I would > prefer this interface. A agree. That's why I called using a new syscall a sledgehammer. Still, I just wanted to remind folk who might think of something better. > signalfd is a special descriptor, so I think it > is not a big deal, that it works a bit strange. Sure, but the more we special case things, the uglier the ABI as a whole becomes. So special casing should be avoided as far as we can. > If all other would > decides, that a new syscall is better, I will not ague. And that's more or less how I see it too. I'm not going to argue for a new syscall, based on what I know so far. Here is one idea to think about though, while more or less maintaining your proposed interface. At the moment, you select signal queues in the pread() call. An alternative would be to do it in the signalfd() call. In other words, you could have the following flags used with signalfd() SFD_RAW SFD_SHARED_QUEUE -- reads will be from process-wide shared signal queue SFD_PER_THREAD_QUEUE --reads will be from per-thread signal queue Specifying both SFD_SHARED_QUEUE and SFD_PER_THREAD_QUEUE would be the same as omitting them both, providing the default behavior of slecting from both queues. My point here is that you can then separate the RAW functionality from the queue selector functionality. Now, it might be that at the moment you always require that if the caller specifies SFD_SHARED_QUEUE or SFD_PER_THREAD_QUEUE, then they must also specify SFD_RAW. But later, that constraint might be relaxed, so that users could use signalfd() to select from a particular queue when reading traditional (non-RAW) signalfd_siginfo structures from a signalfd. This does seem like a very sensible design optimization to make now (and an easy one, I would suppose). What do you think? Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130118] Analyzing a call-trace reproducible with pm_test/freezer [ X86|RCU|TTY|EXT4FS|JBD2|PM related? ]
On Sat, Jan 19, 2013 at 11:59 PM, Sedat Dilek wrote: > On Sat, Jan 19, 2013 at 11:56 PM, Ilya Zykov wrote: >> On 20.01.2013 2:51, Sedat Dilek wrote: >>> On Sat, Jan 19, 2013 at 11:43 PM, Ilya Zykov wrote: Hello! I don't expert, but maybe it can help. I test with: while echo mem > /sys/power/state; do sleep 2; done in one X-terminal, in other I trying playing with keyboard. (Without playing all right I use ext3.) >>> >>> Can you test with the patches listed in [1] (including two TTY patches >>> from you!)? >>> My base is Linux-Next (next-20130118). >>> FYI: My Ubuntu/precise is EXT4FS-formatted. >>> >> Ok. >> but not now I have 3.00 night. >> I already use this in my 3.8.0-rc3-next-20130118-pm+. >> tty: Correct tty buffer flush. >> > > The TTY patches are not enough, you need in addition the JBD2 fix [1]. > Attached is a testcase script which helped here to hit the issue! - Sedat - > - Sedat - > > [1] http://patchwork.ozlabs.org/patch/207237/ > >> run_pm-test.sh Description: Bourne shell script
Re: [next-20130118] Analyzing a call-trace reproducible with pm_test/freezer [ X86|RCU|TTY|EXT4FS|JBD2|PM related? ]
On Sat, Jan 19, 2013 at 11:56 PM, Ilya Zykov wrote: > On 20.01.2013 2:51, Sedat Dilek wrote: >> On Sat, Jan 19, 2013 at 11:43 PM, Ilya Zykov wrote: >>> Hello! >>> I don't expert, but >>> maybe it can help. >>> >>> I test with: >>> while echo mem > /sys/power/state; do sleep 2; done >>> in one X-terminal, in other I trying playing with keyboard. >>> (Without playing all right I use ext3.) >> >> Can you test with the patches listed in [1] (including two TTY patches >> from you!)? >> My base is Linux-Next (next-20130118). >> FYI: My Ubuntu/precise is EXT4FS-formatted. >> > Ok. > but not now I have 3.00 night. > I already use this in my 3.8.0-rc3-next-20130118-pm+. > tty: Correct tty buffer flush. > The TTY patches are not enough, you need in addition the JBD2 fix [1]. - Sedat - [1] http://patchwork.ozlabs.org/patch/207237/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/tty/tty_buffer.c:476 flush_to_ldisc()
On Sat, Jan 19, 2013 at 11:51 PM, Eric Sandeen wrote: > On 1/19/13 4:44 PM, Sedat Dilek wrote: >> Hi Dave, >> >> I suspected after initial testing a problem in TTY and applied two patches. >> After more testing the root cause was a problem in JBD2. >> A patch from Eric helped! > > oh, excellent ;) > > Helped what, exactly? > Fixed a call-trace which I could reproduce running pm_test/freezer (see [1] "[C.1] TRY TO FORCE THE CALL-TRACE"). - Sedat - [1] http://marc.info/?l=linux-kernel=135862010419101=2 >> Follow the thread in [1] for more details. >> >> If you are on Linux-Next (next-20130118) you need the following three >> patches. >> >> Ilya Zykov (2): >> tty: Correct tty buffer flush. >> tty: Add driver unthrottle in ioctl(...,TCFLSH,..). >> >> Eric Sandeen (1): >> jbd2: don't wake kjournald unnecessarily > > Hum, I would not have expected this to *matter*, I thought it was just a perf > optimization. Hm. What do you think it fixed, exactly? > > (sorry, have not followed that thread, busy elsewhere ATM) > > -eric > >> Hope this helps you. >> >> Regards, >> - Sedat - >> >> [0] http://marc.info/?t=13586202374=1=2 >> [1] http://marc.info/?l=linux-serial=135860500714909=2 >> [2] >> http://git.kernel.org/?p=linux/kernel/git/gregkh/tty.git;a=commitdiff;h=a1bf9584429d61b7096f93ae09325e1ba538e9e8 >> [3] http://patchwork.ozlabs.org/patch/207237/ >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130118] Analyzing a call-trace reproducible with pm_test/freezer [ X86|RCU|TTY|EXT4FS|JBD2|PM related? ]
On 20.01.2013 2:51, Sedat Dilek wrote: > On Sat, Jan 19, 2013 at 11:43 PM, Ilya Zykov wrote: >> Hello! >> I don't expert, but >> maybe it can help. >> >> I test with: >> while echo mem > /sys/power/state; do sleep 2; done >> in one X-terminal, in other I trying playing with keyboard. >> (Without playing all right I use ext3.) > > Can you test with the patches listed in [1] (including two TTY patches > from you!)? > My base is Linux-Next (next-20130118). > FYI: My Ubuntu/precise is EXT4FS-formatted. > Ok. but not now I have 3.00 night. I already use this in my 3.8.0-rc3-next-20130118-pm+. tty: Correct tty buffer flush. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/tty/tty_buffer.c:476 flush_to_ldisc()
On 1/19/13 4:44 PM, Sedat Dilek wrote: > Hi Dave, > > I suspected after initial testing a problem in TTY and applied two patches. > After more testing the root cause was a problem in JBD2. > A patch from Eric helped! oh, excellent ;) Helped what, exactly? > Follow the thread in [1] for more details. > > If you are on Linux-Next (next-20130118) you need the following three patches. > > Ilya Zykov (2): > tty: Correct tty buffer flush. > tty: Add driver unthrottle in ioctl(...,TCFLSH,..). > > Eric Sandeen (1): > jbd2: don't wake kjournald unnecessarily Hum, I would not have expected this to *matter*, I thought it was just a perf optimization. Hm. What do you think it fixed, exactly? (sorry, have not followed that thread, busy elsewhere ATM) -eric > Hope this helps you. > > Regards, > - Sedat - > > [0] http://marc.info/?t=13586202374=1=2 > [1] http://marc.info/?l=linux-serial=135860500714909=2 > [2] > http://git.kernel.org/?p=linux/kernel/git/gregkh/tty.git;a=commitdiff;h=a1bf9584429d61b7096f93ae09325e1ba538e9e8 > [3] http://patchwork.ozlabs.org/patch/207237/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130118] Analyzing a call-trace reproducible with pm_test/freezer [ X86|RCU|TTY|EXT4FS|JBD2|PM related? ]
On Sat, Jan 19, 2013 at 11:43 PM, Ilya Zykov wrote: > Hello! > I don't expert, but > maybe it can help. > > I test with: > while echo mem > /sys/power/state; do sleep 2; done > in one X-terminal, in other I trying playing with keyboard. > (Without playing all right I use ext3.) Can you test with the patches listed in [1] (including two TTY patches from you!)? My base is Linux-Next (next-20130118). FYI: My Ubuntu/precise is EXT4FS-formatted. - Sedat - [1] http://marc.info/?l=linux-kernel=135863549723091=2 > And sometimes: > > WARNING: at drivers/tty/tty_buffer.c:427 flush_to_ldisc+0x52/0x192() > Hardware name: P5K Premium > tty is NULL > Restarting tasks ... > Modules linked in: fuse autofs4 af_packet ipt_REJECT nf_conntrack_ipv4 > nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp > nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter > ip6_tables x_tables ipv6 binfmt_misc uinput hid_microsoft hid_generic usbkbd > usbmouse usbhid hid asus_atk0110 iTCO_wdt iTCO_vendor_support evdev sr_mod > cdrom sg ata_generic pata_jmicron coretemp kvm_intel kvm microcode pcspkr > i2c_i801 lpc_ich mfd_core sky2 snd_hda_codec_analog snd_hda_intel > snd_hda_codec snd_seq snd_seq_device snd_pcm snd_timer snd soundcore > snd_page_alloc uhci_hcd nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit > i2c_core mxm_wmi video wmi button intel_agp intel_gtt agpgart > Pid: 263, comm: kworker/1:1 Not tainted 3.8.0-rc3-next-20130118-pm+ #16 > Call Trace: > [] warn_slowpath_common+0x80/0x98 > [] warn_slowpath_fmt+0x41/0x43 > [] flush_to_ldisc+0x52/0x192 > [] ? console_unlock+0x2f4/0x319 > [] process_one_work+0x1e1/0x2a0 > [] worker_thread+0x154/0x24e > [] ? manage_workers+0x26c/0x26c > [] kthread+0xb0/0xb8 > [] ? kthread_freezable_should_stop+0x60/0x60 > [] ret_from_fork+0x7c/0xb0 > [] ? kthread_freezable_should_stop+0x60/0x60 > > > Also maybe you will be intresting this: > https://lkml.org/lkml/2012/12/18/368 > > > Cpu model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > My .config: > CONFIG_64BIT=y > CONFIG_X86_64=y > CONFIG_X86=y > CONFIG_INSTRUCTION_DECODER=y > CONFIG_OUTPUT_FORMAT="elf64-x86-64" > CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" > CONFIG_LOCKDEP_SUPPORT=y > CONFIG_STACKTRACE_SUPPORT=y > CONFIG_HAVE_LATENCYTOP_SUPPORT=y > CONFIG_MMU=y > CONFIG_NEED_DMA_MAP_STATE=y > CONFIG_NEED_SG_DMA_LENGTH=y > CONFIG_GENERIC_ISA_DMA=y > CONFIG_GENERIC_BUG=y > CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y > CONFIG_GENERIC_HWEIGHT=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > CONFIG_RWSEM_XCHGADD_ALGORITHM=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > CONFIG_ARCH_HAS_CPU_RELAX=y > CONFIG_ARCH_HAS_DEFAULT_IDLE=y > CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y > CONFIG_ARCH_HAS_CPU_AUTOPROBE=y > CONFIG_HAVE_SETUP_PER_CPU_AREA=y > CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y > CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y > CONFIG_ARCH_HIBERNATION_POSSIBLE=y > CONFIG_ARCH_SUSPEND_POSSIBLE=y > CONFIG_ZONE_DMA32=y > CONFIG_AUDIT_ARCH=y > CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y > CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y > CONFIG_HAVE_INTEL_TXT=y > CONFIG_X86_64_SMP=y > CONFIG_X86_HT=y > CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi > -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 > -fcall-saved-r10 -fcall-saved-r11" > CONFIG_ARCH_CPU_PROBE_RELEASE=y > CONFIG_ARCH_SUPPORTS_UPROBES=y > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > CONFIG_IRQ_WORK=y > CONFIG_BUILDTIME_EXTABLE_SORT=y > CONFIG_EXPERIMENTAL=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > CONFIG_CROSS_COMPILE="" > CONFIG_LOCALVERSION="-pm" > CONFIG_HAVE_KERNEL_GZIP=y > CONFIG_HAVE_KERNEL_BZIP2=y > CONFIG_HAVE_KERNEL_LZMA=y > CONFIG_HAVE_KERNEL_XZ=y > CONFIG_HAVE_KERNEL_LZO=y > CONFIG_KERNEL_GZIP=y > CONFIG_DEFAULT_HOSTNAME="(none)" > CONFIG_SWAP=y > CONFIG_SYSVIPC=y > CONFIG_SYSVIPC_SYSCTL=y > CONFIG_POSIX_MQUEUE=y > CONFIG_POSIX_MQUEUE_SYSCTL=y > CONFIG_FHANDLE=y > CONFIG_AUDIT=y > CONFIG_AUDITSYSCALL=y > CONFIG_AUDIT_WATCH=y > CONFIG_AUDIT_TREE=y > CONFIG_AUDIT_LOGINUID_IMMUTABLE=y > CONFIG_HAVE_GENERIC_HARDIRQS=y > CONFIG_GENERIC_HARDIRQS=y > CONFIG_GENERIC_IRQ_PROBE=y > CONFIG_GENERIC_IRQ_SHOW=y > CONFIG_GENERIC_PENDING_IRQ=y > CONFIG_IRQ_DOMAIN=y > CONFIG_IRQ_FORCED_THREADING=y > CONFIG_SPARSE_IRQ=y > CONFIG_CLOCKSOURCE_WATCHDOG=y > CONFIG_ARCH_CLOCKSOURCE_DATA=y > CONFIG_GENERIC_TIME_VSYSCALL=y > CONFIG_GENERIC_CLOCKEVENTS=y > CONFIG_GENERIC_CLOCKEVENTS_BUILD=y > CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y > CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y > CONFIG_GENERIC_CMOS_UPDATE=y > CONFIG_TICK_ONESHOT=y > CONFIG_NO_HZ=y > CONFIG_HIGH_RES_TIMERS=y > CONFIG_TICK_CPU_ACCOUNTING=y > CONFIG_BSD_PROCESS_ACCT=y > CONFIG_BSD_PROCESS_ACCT_V3=y > CONFIG_TASKSTATS=y > CONFIG_TASK_DELAY_ACCT=y > CONFIG_TREE_RCU=y > CONFIG_RCU_STALL_COMMON=y > CONFIG_RCU_FANOUT=64 > CONFIG_RCU_FANOUT_LEAF=16 > CONFIG_IKCONFIG=m > CONFIG_IKCONFIG_PROC=y > CONFIG_LOG_BUF_SHIFT=20 > CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y >
Re: [next-20130118] Analyzing a call-trace reproducible with pm_test/freezer [ X86|RCU|TTY|EXT4FS|JBD2|PM related? ]
Hello! I don't expert, but maybe it can help. I test with: while echo mem > /sys/power/state; do sleep 2; done in one X-terminal, in other I trying playing with keyboard. (Without playing all right I use ext3.) And sometimes: WARNING: at drivers/tty/tty_buffer.c:427 flush_to_ldisc+0x52/0x192() Hardware name: P5K Premium tty is NULL Restarting tasks ... Modules linked in: fuse autofs4 af_packet ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 binfmt_misc uinput hid_microsoft hid_generic usbkbd usbmouse usbhid hid asus_atk0110 iTCO_wdt iTCO_vendor_support evdev sr_mod cdrom sg ata_generic pata_jmicron coretemp kvm_intel kvm microcode pcspkr i2c_i801 lpc_ich mfd_core sky2 snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc uhci_hcd nouveau ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core mxm_wmi video wmi button intel_agp intel_gtt agpgart Pid: 263, comm: kworker/1:1 Not tainted 3.8.0-rc3-next-20130118-pm+ #16 Call Trace: [] warn_slowpath_common+0x80/0x98 [] warn_slowpath_fmt+0x41/0x43 [] flush_to_ldisc+0x52/0x192 [] ? console_unlock+0x2f4/0x319 [] process_one_work+0x1e1/0x2a0 [] worker_thread+0x154/0x24e [] ? manage_workers+0x26c/0x26c [] kthread+0xb0/0xb8 [] ? kthread_freezable_should_stop+0x60/0x60 [] ret_from_fork+0x7c/0xb0 [] ? kthread_freezable_should_stop+0x60/0x60 Also maybe you will be intresting this: https://lkml.org/lkml/2012/12/18/368 Cpu model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz My .config: CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_CPU_PROBE_RELEASE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_EXPERIMENTAL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="-pm" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_FHANDLE=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y CONFIG_AUDIT_LOGINUID_IMMUTABLE=y CONFIG_HAVE_GENERIC_HARDIRQS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_TICK_CPU_ACCOUNTING=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TREE_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=20 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_UIDGID_CONVERTED=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EXPERT=y CONFIG_HAVE_UID16=y CONFIG_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y
Re: [PATCH v3 4/8] MFD: ti_am335x_tscadc: add device tree binding information
Hi,
On 01/18/2013 11:48 AM, Patil, Rachna wrote:
> From: "Patil, Rachna"
>
> Signed-off-by: Patil, Rachna
> ---
> .../devicetree/bindings/mfd/ti_am335x_tscadc.txt | 35
>
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> new file mode 100644
> index 000..c13c492
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> @@ -0,0 +1,35 @@
> +Texas Instruments - TSC / ADC multi-functional device
> +
> +ti_tscadc is a multi-function device with touchscreen and ADC on chip.
> +This document describes the binding for mfd device.
> +
> +Required properties:
> +- compatible: "ti,ti-tscadc"
> +- reg: Specifies the address of MFD block
> +- interrupts: IRQ line connected to the main SoC
> +- interrupt-parent: The parent interrupt controller
The subnodes and their properties also need documentation.
> +
> +Optional properties:
> +- ti,hwmods: Hardware information related to TSC/ADC MFD device
> +
> +Example:
> +
> + tscadc: tscadc@44e0d000 {
> + compatible = "ti,ti-tscadc";
> + reg = <0x44e0d000 0x1000>;
> +
> + interrupt-parent = <>;
> + interrupts = <16>;
> + ti,hwmods = "adc_tsc";
> +
> + tsc {
> + wires = <4>;
> + x-plate-resistance = <200>;
> + steps-to-configure = <5>;
> + wire-config = <0x00 0x11 0x22 0x33>;
Non-standard properties should have a vendor prefix.
> + };
> +
> + adc {
> + adc-channels = <4>;
> + };
> + };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux detects only 2.6GiB RAM in legacy boot
On Sat, Jan 19, 2013 at 10:43 AM, richard -rw- weinberger wrote: > Hi, > > My shiny new Thinkpad T430u comes with UEFI. > To avoid broken bootloaders/distros I've enabled legacy boot mode. > > But Linux seems to detect only 2.6GB of RAM. > [0.00] On node 0 totalpages: 1008669 > vs. > [0.00] On node 0 totalpages: 701239 > > Both dmesg logs are attached. > This happens also with 3.7.x. > > Is there anything I can do or is this a plain UEFI/BIOS bug? looks like BIOS problem: UEFI one: [0.00] BIOS-e820: [mem 0x-0x0008] usable [0.00] BIOS-e820: [mem 0x0009-0x000b] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable [0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved [0.00] BIOS-e820: [mem 0x40005000-0x8f465fff] usable [0.00] BIOS-e820: [mem 0x8f466000-0x8f667fff] reserved [0.00] BIOS-e820: [mem 0x8f668000-0xd829efff] usable [0.00] BIOS-e820: [mem 0xd829f000-0xdae9efff] reserved [0.00] BIOS-e820: [mem 0xdae9f000-0xdaf9efff] ACPI NVS [0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data [0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable [0.00] BIOS-e820: [mem 0xdb00-0xdf9f] reserved [0.00] BIOS-e820: [mem 0xf80f8000-0xf80f8fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0x0001-0x00011e5f] usable legacy one: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable [0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved [0.00] BIOS-e820: [mem 0x40005000-0x8cfaafff] usable [0.00] BIOS-e820: [mem 0x8cfab000-0xdae9efff] reserved [0.00] BIOS-e820: [mem 0xdae9f000-0xdaf9efff] ACPI NVS [0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data [0.00] BIOS-e820: [mem 0xdafff000-0xdf9f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffc0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00011e5f] usable So difference: [0.00] BIOS-e820: [mem 0x8f466000-0x8f667fff] reserved [0.00] BIOS-e820: [mem 0x8f668000-0xd829efff] usable [0.00] BIOS-e820: [mem 0xd829f000-0xdae9efff] reserved to [0.00] BIOS-e820: [mem 0x8cfab000-0xdae9efff] reserved at least about 1G get lost in e820. Can you please apply attached patch to see the raw e820? Thanks Yinghai print_raw_e820.patch Description: Binary data
Re: [next-20130118] Analyzing a call-trace reproducible with pm_test/freezer [ X86|RCU|TTY|EXT4FS|JBD2|PM related? ]
On Sat, Jan 19, 2013 at 9:48 PM, Sedat Dilek wrote:
> On Sat, Jan 19, 2013 at 7:28 PM, Sedat Dilek wrote:
>> Hi,
>>
>> I am still stepping in the dark how track this problem down.
>> If you have useful (debug) help, you are welcome.
>>
>> Regards,
>> - Sedat -
>>
>> # ANALYZING CALL-TRACES SEEN IN LINUX-NEXT-20130118 #
>>
>> # INTRO
>>
>> ### MY LINUX-SYSTEM
>>
>> I am running here Ubuntu/precise AMD64 in a WUBI environment.
>> The system was formatted with EXT4-FS.
>>
>> ### MY LINUX-KERNEL
>>
>> My own built Linux-Next (next-20130118) kernel includes some additional
>> patches,
>> especially a TTY-NEXT fix from Ilya Zykov.
>>
>> See also attached kernel-config file, dmesg and lspci outputs.
>>
>> ### SOME USEFUL KERNEL DEBUG OPTIONS
>>
>> CONFIG_PM_DEBUG=y
>> CONFIG_EXT4_DEBUG=y
>> CONFIG_JBD2_DEBUG=y
>>
>>
>> # [A] ANALYZING LAST REBOOT
>>
>> ### [A.1] MESSAGES
>>
>> # Messages #1: DBUS related?
>> nm-dispatcher.action: Could not get the system bus. Make sure the
>> message bus daemon is running! Message: Failed to connect to socket
>> /var/run/dbus/system_bus_socket: No such file or directory
>>
>> # Messages #2: RCU_SCHED related?
>> INFO: rcu_sched detected stalls on CPUs/tasks: { 2 3} (detected by 1,
>> t=15004 jiffies, g=70928, c=70927, q=15)
>> INFO: task kworker/0:1:37 blocked for more than 120 seconds. "echo 0 >
>> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>>
>> ### [A.2] ANALYZING DBUS PROBLEM
>>
>> # ll /var/run/dbus/system_bus_socket*
>> srwxrwxrwx 1 root root 0 Jan 19 17:08 /var/run/dbus/system_bus_socket=
>>
>> # ll /var/run/dbus/
>> insgesamt 4
>> drwxr-xr-x 2 messagebus messagebus 80 Jan 19 17:08 ./
>> drwxr-xr-x 22 root root 800 Jan 19 17:11 ../
>> -rw-r--r-- 1 root root 4 Jan 19 17:08 pid
>> srwxrwxrwx 1 root root 0 Jan 19 17:08 system_bus_socket=
>>
>> # cat /var/run/dbus/pid
>> 862
>>
>> # ps axu | grep -v grep | grep 862
>> 102862 0.2 0.0 25492 2332 ?Ss 17:08 0:01
>> dbus-daemon --system --fork --activation=upstart
>>
>> # pidof dbus-daemon
>> 1921 862
>>
>> ### [A.3] ANALYZING RCU_SCHED PROBLEM
>>
>> # cat /proc/sys/kernel/hung_task_timeout_secs
>> 120
>>
>>
>> # [B] TESTCASE DESCRIPTION
>>
>> ### [B.1] TESTCASE #1: Do a "normal" suspend and resume
>>
>> Select "suspend" (DE: "Bereitschaft") from system's menue within
>> Ubuntu/unity.
>>
>> ### [B.2] TESTCASE #2: Run pm_test/freezer (PREREQ: CONFIG_PM_DEBUG=y)
>>
>> HELP:
>>
>>
>> # cat /sys/power/pm_test
>> [none] core processors platform devices freezer
>>
>> # echo "freezer" > /sys/power/pm_test
>> # cat /sys/power/pm_test
>> none core processors platform devices [freezer]
>>
>> # echo mem > /sys/power/state && sleep 1 <--- LOOP until you see a call-trace
>>
>> ### [B.3] TESTCASE #3: Change "hung_task_timeout_secs" before running
>> pm_test/freezer
>>
>> # cat /proc/sys/kernel/hung_task_timeout_secs
>> 120
>>
>> # echo 0 > /proc/sys/kernel/hung_task_timeout_secs
>> # cat /proc/sys/kernel/hung_task_timeout_secs
>> 0
>>
>>
>> # [C] THE CALL-TRACE
>>
>> ### [C.1] TRY TO FORCE THE CALL-TRACE
>>
>> The call-trace is not ***always*** reproducible!
>> Even with "0" for "hung_task_timeout_secs" it is seen (see testcase #3)!
>>
>> The call-trace ***always*** happened when the output "-su: echo: write
>> error: Device or resource busy" was seen!
>> Unsure, how to intpret it!
>> What means "-su"?
>> Write-error to which device?
>> Which resource is busy?
>>
>> # LC_ALL=C echo mem > /sys/power/state && sleep 1
>> -su: echo: write error: Device or resource busy <--- THIS OUTPUT!
>>
>> [ /var/log/kern.log ]
>>
>> n 19 18:00:02 fambox kernel: [ 3065.559184] PM: Syncing filesystems ... done.
>> Jan 19 18:00:02 fambox kernel: [ 3065.768458] PM: Preparing system for mem
>> sleep
>> Jan 19 18:00:14 fambox kernel: [ 3072.733178] Freezing user space
>> processes ... (elapsed 0.01 seconds) done.
>> Jan 19 18:00:14 fambox kernel: [ 3072.749284] Freezing remaining
>> freezable tasks ... (elapsed 0.01 seconds) done.
>> Jan 19 18:00:14 fambox kernel: [ 3072.765274] suspend debug: Waiting
>> for 5 seconds.
>> Jan 19 18:00:14 fambox kernel: [ 3077.72] PM: Finishing wakeup.
>> Jan 19 18:00:14 fambox kernel: [ 3077.74] Restarting tasks ... done.
>> Jan 19 18:00:14 fambox kernel: [ 3077.726719] video LNXVIDEO:00:
>> Restoring backlight state
>> Jan 19 18:00:18 fambox kernel: [ 3081.596512] PM: Syncing filesystems ...
>> done.
>> Jan 19 18:00:18 fambox kernel: [ 3081.750235] PM: Preparing system for mem
>> sleep
>> Jan 19 18:00:45 fambox kernel: [ 3087.738204] Freezing user space
>> processes ... (elapsed 0.04 seconds) done.
>> Jan 19 18:00:45 fambox kernel: [ 3087.786660] Freezing remaining
>> freezable tasks ...
>> Jan 19 18:00:45 fambox kernel: [ 3107.788540] Freezing of tasks failed
>> after 20.01 seconds (1
Re: [lttng-dev] [PATCH] Add ACCESS_ONCE() to avoid compiler splitting assignments
On Wed, Jan 16, 2013 at 07:50:54AM -0500, Mathieu Desnoyers wrote:
> * Mathieu Desnoyers (mathieu.desnoy...@efficios.com) wrote:
> > * Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> > > As noted by Konstantin Khlebnikov, gcc can split assignment of
> > > constants to long variables (https://lkml.org/lkml/2013/1/15/141),
> > > though assignment of NULL (0) is OK. Assuming that a gcc bug is
> > > fixed (http://gcc.gnu.org/bugzilla/attachment.cgi?id=29169=diff
> > > has a patch), making the store be volatile keeps gcc from splitting.
> > >
> > > This commit therefore applies ACCESS_ONCE() to CMM_STORE_SHARED(),
> > > which is the underlying primitive used by rcu_assign_pointer().
> >
> > Hi Paul,
> >
> > I recognise that this is an issue in the Linux kernel, since a simple
> > store is used and expected to be performed atomically when aligned.
> > However, I think this does not affect liburcu, see below:
>
> Side question: what gcc versions may issue non-atomic volatile stores ?
> I think we should at least document those. Bug
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 seems to target gcc
> 4.7.2, but I wonder when this issue first appeared on x86 and x86-64
> (and if it affects other architectures as well).
I have no idea which versions are affected. The bug is in the x86
backend, so is specific to x86, but there might well be similar bugs
in other architectures.
> Thanks,
>
> Mathieu
>
> >
> > >
> > > Signed-off-by: Paul E. McKenney
> > >
> > > diff --git a/urcu/system.h b/urcu/system.h
> > > index 2a45f22..7a1887e 100644
> > > --- a/urcu/system.h
> > > +++ b/urcu/system.h
> > > @@ -49,7 +49,7 @@
> > > */
> > > #define CMM_STORE_SHARED(x, v) \
> > > ({ \
> > > - __typeof__(x) _v = _CMM_STORE_SHARED(x, v); \
> > > + __typeof__(x) CMM_ACCESS_ONCE(_v) = _CMM_STORE_SHARED(x, v);
> > > \
> >
> > Here, the macro "_CMM_STORE_SHARED(x, v)" is doing the actual store.
> > It stores v into "x". So adding a CMM_ACCESS_ONCE(_v), as you propose
> > here, is really only making sure the return value (usually unused),
> > located on the stack, is accessed with a volatile access, which does not
> > make much sense.
> >
> > What really matters is the _CMM_STORE_SHARED() macro:
> >
> > #define _CMM_STORE_SHARED(x, v) ({ CMM_ACCESS_ONCE(x) = (v); })
> >
> > which already uses a volatile access for the store. So this seems to be
> > a case where our preemptive use of volatile for stores in addition to
> > loads made us bug-free for a gcc behavior unexpected at the time we
> > implemented this macro. Just a touch of paranoia seems to be a good
> > thing sometimes. ;-)
> >
> > Thoughts ?
Here is my thought: You should ignore my "fix". Please accept my
apologies for my confusion!
Thanx, Paul
> > Thanks,
> >
> > Mathieu
> >
> > > cmm_smp_wmc(); \
> > > _v; \
> > > })
> > >
> > >
> > > ___
> > > lttng-dev mailing list
> > > lttng-...@lists.lttng.org
> > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> >
> > --
> > Mathieu Desnoyers
> > EfficiOS Inc.
> > http://www.efficios.com
> >
> > ___
> > lttng-dev mailing list
> > lttng-...@lists.lttng.org
> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/tty/tty_buffer.c:476 (tty is NULL)
On 01/18/2013 10:07 PM, Greg Kroah-Hartman wrote: > Jiri, was there anything on the mailing list that I missed that should > have resolved this issue? I thought it was being worked on, but I can't > seem to find any resolution at the moment. Somebody had a patchset and promised to repost IIRC. I forgot his name though. /me back from digging in the mail history. Peter Hurley is the name. Peter, what happened with your patches in the end, please? thanks, -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130118] Analyzing a call-trace reproducible with pm_test/freezer [ X86|RCU|TTY|EXT4FS|JBD2|PM related? ]
On Sat, Jan 19, 2013 at 7:28 PM, Sedat Dilek wrote:
> Hi,
>
> I am still stepping in the dark how track this problem down.
> If you have useful (debug) help, you are welcome.
>
> Regards,
> - Sedat -
>
> # ANALYZING CALL-TRACES SEEN IN LINUX-NEXT-20130118 #
>
> # INTRO
>
> ### MY LINUX-SYSTEM
>
> I am running here Ubuntu/precise AMD64 in a WUBI environment.
> The system was formatted with EXT4-FS.
>
> ### MY LINUX-KERNEL
>
> My own built Linux-Next (next-20130118) kernel includes some additional
> patches,
> especially a TTY-NEXT fix from Ilya Zykov.
>
> See also attached kernel-config file, dmesg and lspci outputs.
>
> ### SOME USEFUL KERNEL DEBUG OPTIONS
>
> CONFIG_PM_DEBUG=y
> CONFIG_EXT4_DEBUG=y
> CONFIG_JBD2_DEBUG=y
>
>
> # [A] ANALYZING LAST REBOOT
>
> ### [A.1] MESSAGES
>
> # Messages #1: DBUS related?
> nm-dispatcher.action: Could not get the system bus. Make sure the
> message bus daemon is running! Message: Failed to connect to socket
> /var/run/dbus/system_bus_socket: No such file or directory
>
> # Messages #2: RCU_SCHED related?
> INFO: rcu_sched detected stalls on CPUs/tasks: { 2 3} (detected by 1,
> t=15004 jiffies, g=70928, c=70927, q=15)
> INFO: task kworker/0:1:37 blocked for more than 120 seconds. "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>
> ### [A.2] ANALYZING DBUS PROBLEM
>
> # ll /var/run/dbus/system_bus_socket*
> srwxrwxrwx 1 root root 0 Jan 19 17:08 /var/run/dbus/system_bus_socket=
>
> # ll /var/run/dbus/
> insgesamt 4
> drwxr-xr-x 2 messagebus messagebus 80 Jan 19 17:08 ./
> drwxr-xr-x 22 root root 800 Jan 19 17:11 ../
> -rw-r--r-- 1 root root 4 Jan 19 17:08 pid
> srwxrwxrwx 1 root root 0 Jan 19 17:08 system_bus_socket=
>
> # cat /var/run/dbus/pid
> 862
>
> # ps axu | grep -v grep | grep 862
> 102862 0.2 0.0 25492 2332 ?Ss 17:08 0:01
> dbus-daemon --system --fork --activation=upstart
>
> # pidof dbus-daemon
> 1921 862
>
> ### [A.3] ANALYZING RCU_SCHED PROBLEM
>
> # cat /proc/sys/kernel/hung_task_timeout_secs
> 120
>
>
> # [B] TESTCASE DESCRIPTION
>
> ### [B.1] TESTCASE #1: Do a "normal" suspend and resume
>
> Select "suspend" (DE: "Bereitschaft") from system's menue within Ubuntu/unity.
>
> ### [B.2] TESTCASE #2: Run pm_test/freezer (PREREQ: CONFIG_PM_DEBUG=y)
>
> HELP:
>
>
> # cat /sys/power/pm_test
> [none] core processors platform devices freezer
>
> # echo "freezer" > /sys/power/pm_test
> # cat /sys/power/pm_test
> none core processors platform devices [freezer]
>
> # echo mem > /sys/power/state && sleep 1 <--- LOOP until you see a call-trace
>
> ### [B.3] TESTCASE #3: Change "hung_task_timeout_secs" before running
> pm_test/freezer
>
> # cat /proc/sys/kernel/hung_task_timeout_secs
> 120
>
> # echo 0 > /proc/sys/kernel/hung_task_timeout_secs
> # cat /proc/sys/kernel/hung_task_timeout_secs
> 0
>
>
> # [C] THE CALL-TRACE
>
> ### [C.1] TRY TO FORCE THE CALL-TRACE
>
> The call-trace is not ***always*** reproducible!
> Even with "0" for "hung_task_timeout_secs" it is seen (see testcase #3)!
>
> The call-trace ***always*** happened when the output "-su: echo: write
> error: Device or resource busy" was seen!
> Unsure, how to intpret it!
> What means "-su"?
> Write-error to which device?
> Which resource is busy?
>
> # LC_ALL=C echo mem > /sys/power/state && sleep 1
> -su: echo: write error: Device or resource busy <--- THIS OUTPUT!
>
> [ /var/log/kern.log ]
>
> n 19 18:00:02 fambox kernel: [ 3065.559184] PM: Syncing filesystems ... done.
> Jan 19 18:00:02 fambox kernel: [ 3065.768458] PM: Preparing system for mem
> sleep
> Jan 19 18:00:14 fambox kernel: [ 3072.733178] Freezing user space
> processes ... (elapsed 0.01 seconds) done.
> Jan 19 18:00:14 fambox kernel: [ 3072.749284] Freezing remaining
> freezable tasks ... (elapsed 0.01 seconds) done.
> Jan 19 18:00:14 fambox kernel: [ 3072.765274] suspend debug: Waiting
> for 5 seconds.
> Jan 19 18:00:14 fambox kernel: [ 3077.72] PM: Finishing wakeup.
> Jan 19 18:00:14 fambox kernel: [ 3077.74] Restarting tasks ... done.
> Jan 19 18:00:14 fambox kernel: [ 3077.726719] video LNXVIDEO:00:
> Restoring backlight state
> Jan 19 18:00:18 fambox kernel: [ 3081.596512] PM: Syncing filesystems ...
> done.
> Jan 19 18:00:18 fambox kernel: [ 3081.750235] PM: Preparing system for mem
> sleep
> Jan 19 18:00:45 fambox kernel: [ 3087.738204] Freezing user space
> processes ... (elapsed 0.04 seconds) done.
> Jan 19 18:00:45 fambox kernel: [ 3087.786660] Freezing remaining
> freezable tasks ...
> Jan 19 18:00:45 fambox kernel: [ 3107.788540] Freezing of tasks failed
> after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0):
> Jan 19 18:00:45 fambox kernel: [ 3107.788664] jbd2/loop0-8D
> 8180d780 0 299 2 0x
> Jan 19 18:00:45 fambox kernel: [ 3107.788673]
[Update][PATCH] ACPI / PM: Export power states of ACPI devices via sysfs
From: Rafael J. Wysocki
Subject: ACPI / PM: Export power states of ACPI devices via sysfs
Make it possible to retrieve the current power state of a device with
ACPI power management from user space via sysfs by adding a new
attribute power_state to the sysfs directory associated with the
struct acpi_device object representing the device's ACPI node.
Signed-off-by: Rafael J. Wysocki
---
I've changed my mind here. It looks like it's more convenient to put the
power_state attribute directly into the ACPI device node's directory in sysfs
rather than into its power subdirectory.
Thanks,
Rafael
---
Documentation/ABI/testing/sysfs-devices-power | 13 +
drivers/acpi/scan.c | 25 -
2 files changed, 37 insertions(+), 1 deletion(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -184,6 +184,19 @@ err_out:
}
EXPORT_SYMBOL(acpi_bus_hot_remove_device);
+static ssize_t power_state_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct acpi_device *adev = to_acpi_device(dev);
+ int state;
+ int ret;
+
+ ret = acpi_device_get_power(adev, );
+ return ret ? ret : sprintf(buf, "%s\n", acpi_power_state_string(state));
+}
+
+static DEVICE_ATTR(power_state, 0444, power_state_show, NULL);
+
static ssize_t
acpi_eject_store(struct device *d, struct device_attribute *attr,
const char *buf, size_t count)
@@ -375,8 +388,15 @@ static int acpi_device_setup_files(struc
* hot-removal function from userland.
*/
status = acpi_get_handle(dev->handle, "_EJ0", );
- if (ACPI_SUCCESS(status))
+ if (ACPI_SUCCESS(status)) {
result = device_create_file(>dev, _attr_eject);
+ if (result)
+ goto end;
+ }
+
+ if (dev->flags.power_manageable)
+ result = device_create_file(>dev, _attr_power_state);
+
end:
return result;
}
@@ -386,6 +406,9 @@ static void acpi_device_remove_files(str
acpi_status status;
acpi_handle temp;
+ if (dev->flags.power_manageable)
+ device_remove_file(>dev, _attr_power_state);
+
/*
* If device has _STR, remove 'description' file
*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: btmrvl_sdio: look for sd8688 firmware in proper location
Hi Lubomir, > The firmware images are shared with libertas_sdio WiFi chip and used to be in > libertas/ subtree in linux-firmware. As btmrvl_sdio used to look into the > linux-firmware root, it ended up being unsuccessful. Since the firmware files > are not specific to the libertas hardware, they're being moved into mrvl/ now. > > Signed-off-by: Lubomir Rintel > --- > drivers/bluetooth/btmrvl_sdio.c |8 > 1 files changed, 4 insertions(+), 4 deletions(-) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.8-rc1: compiling problem in perf-event-p6.o
This didn't happen on 3.6 (3.7 I had no time to check out), although I continue to use the same c compiler and libraries. So it should be caused by any change of the subroutine perf_event_p6 made in the last time. Also, everything else of the kernel compiled, just not that subroutine. Anyway the kernel should compile correctly with all recent versions of the c compiler, so one should search and fix that. The maintainer of that subroutine should be notified, and check the last changes since 3.6 . Also, I always compile the WHOLE kernel, not only changed subroutines. Perhaps in any other subroutine was changed something of global variables in any other subroutine, what is now incompatible with subroutine perf_event_p6 W.Landgraf = On Wed, 16 Jan 2013 17:26:33 -0800 Randy Dunlap wrote: On 01/15/13 06:50, werner wrote: We are now on -rc3 and someone should correct this, finally This is a regression, it was not before, on 3.6 This messes up any compilation of the whole kernel, it results in don't be produced vmlinuz arch/x86/kernel/cpu/perf_event_p6.o depends on so much things that I don't get it switched off, I suppose it's necesary for the most systems W.Landgraf = The problem continues with 3.8-rc This is grave, no vmlinuz is produced. wl CC arch/x86/kernel/cpu/perf_event.o CC arch/x86/kernel/cpu/perf_event_amd.o CC arch/x86/kernel/cpu/perf_event_p6.o arch/x86/kernel/cpu/perf_event_p6.c:22: error: p6_hw_cache_event_ids causes a section type conflict make[3]: [arch/x86/kernel/cpu/perf_event_p6.o] Error 1 (ignored) CC arch/x86/kernel/cpu/perf_event_knc.o CC arch/x86/kernel/cpu/perf_event_p4.o CC arch/x86/kernel/cpu/perf_event_intel_lbr.o There ocurs a compiling error in perf-event-p6.o , any regression, unfortunately I lost the compiling list but I think it was any incompatibility / redefinition with something else, pls check and correct that, if not already done W.Landgraf Hi, I don't see this problem on 3.8-rc1 or -rc3. Maybe a difference/problem in gcc?? -- ~Randy "werner" --- Professional hosting for everyone - http://www.host.ru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
On Saturday 19 January 2013, Soeren Moch wrote: > What I can see in the log: a lot of coherent mappings from sata_mv and > orion_ehci, a few from mv643xx_eth, no other coherent mappings. > All coherent mappings are page aligned, some of them (from orion_ehci) > are not really small (as claimed in __alloc_from_pool). Right. Unfortunately, the output does not show which of the mappings are atomic, so we still need to look through those that can be atomic to understand what's going on. There are a few megabytes of coherent mappings in total according to the output, but it seems that a significant portion of them is atomic, which is a bit unexpected. > I don't believe in a memory leak. When I restart vdr (the application > utilizing the dvb sticks) then there is enough dma memory available > again. I found at least one source line that incorrectly uses an atomic allocation, in ehci_mem_init(): dma_alloc_coherent (ehci_to_hcd(ehci)->self.controller, ehci->periodic_size * sizeof(__le32), >periodic_dma, 0); The last argument is the GFP_ flag, which should never be zero, as that is implicit !wait. This function is called only once, so it is not the actual culprit, but there could be other instances where we accidentally allocate something as GFP_ATOMIC. The total number of allocations I found for each type are sata_mv: 66 pages (270336 bytes) mv643xx_eth: 4 pages == (16384 bytes) orion_ehci: 154 pages (630784 bytes) orion_ehci (atomic): 256 pages (1048576 bytes) from the distribution of the numbers, it seems that there is exactly 1 MB of data allocated between bus addresses 0x1f9 and 0x1f9, allocated in individual pages. This matches the size of your pool, so it's definitely something coming from USB, and no single other allocation, but it does not directly point to a specific line of code. One thing I found was that the ARM dma-mapping code seems buggy in the way that it does a bitwise and between the gfp mask and GFP_ATOMIC, which does not work because GFP_ATOMIC is defined by the absence of __GFP_WAIT. I believe we need the patch below, but it is not clear to me if that issue is related to your problem or now. diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 6b2fb87..c57975f 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -640,7 +641,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle, if (is_coherent || nommu()) addr = __alloc_simple_buffer(dev, size, gfp, ); - else if (gfp & GFP_ATOMIC) + else if (!(gfp & __GFP_WAIT)) addr = __alloc_from_pool(size, ); else if (!IS_ENABLED(CONFIG_CMA)) addr = __alloc_remap_buffer(dev, size, gfp, prot, , caller); @@ -1272,7 +1273,7 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size, *handle = DMA_ERROR_CODE; size = PAGE_ALIGN(size); - if (gfp & GFP_ATOMIC) + if (!(gfp & __GFP_WAIT)) return __iommu_alloc_atomic(dev, size, handle); pages = __iommu_alloc_buffer(dev, size, gfp, attrs); 8<--- There is one more code path I could find, which is usb_submit_urb() => usb_hcd_submit_urb => ehci_urb_enqueue() => submit_async() => qh_append_tds() => qh_make(GFP_ATOMIC) => ehci_qh_alloc() => dma_pool_alloc() => pool_alloc_page() => dma_alloc_coherent() So even for a GFP_KERNEL passed into usb_submit_urb, the ehci driver causes the low-level allocation to be GFP_ATOMIC, because qh_append_tds() is called under a spinlock. If we have hundreds of URBs in flight, that will exhaust the pool rather quickly. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IIO ADC support for AD7923
Hi,
On 01/19/2013 04:05 PM, christophe leroy wrote:
> Hi Lars,
>
> Sorry to respond so late, I've been very busy lately.
> Please see answers/questions below
>
> Main point is that our driver is mainly copied and adapted from AD7298
> driver, and your comments are on things that we have not modified from
> AD7298, so what should we do really ?
The AD7288 driver has recently seen some updates. The issues which your driver
inherited from the AD7288 driver have been fixed in the original driver. See:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/iio/adc/ad7298.c;h=b34d754994d50d53f60fee694440658ba0b137dd;hb=HEAD
>
> We are a bit new comers in Kernel Development, so thanks for your help.
>
> Christophe
>
> Le 08/01/2013 11:27, Lars-Peter Clausen a écrit :
>> On 01/08/2013 09:42 AM, Christophe Leroy wrote:
>>> This patch adds support for Analog Devices AD7923 ADC in the IIO
>>> Subsystem.
>>>
>>> Signed-off-by: Patrick Vasseur
>>> Signed-off-by: Christophe Leroy
>> Hi,
>>
>> Thanks for the driver, looks pretty good. Some comments inline.
>>
>> - Lars
>>
>>> diff -uN linux-3.7.1/drivers/staging/iio/adc/Kconfig
>>> linux/drivers/staging/iio/adc/Kconfig
>>> --- linux-3.7.1/drivers/staging/iio/adc/Kconfig2012-12-17
>>> 20:14:54.0 +0100
>>> +++ linux/drivers/staging/iio/adc/Kconfig2012-12-13
>>> 19:52:10.0 +0100
>> New IIO drivers should not be added to staging, unless there is a very
>> good
>> reason. Since this driver does not have any major issues it should
>> directly go
>> into drivers/iio/
> Our driver is based on AD7298 driver, which is today in staging. Should
> we put ours in drivers/iio/ directly anyway ?
>>
>> [...]
>>
[...]
>>> diff -uN linux-3.7.1/drivers/staging/iio/adc/ad7923_core.c
>>> linux/drivers/staging/iio/adc/ad7923_core.c
>>> --- linux-3.7.1/drivers/staging/iio/adc/ad7923_core.c1970-01-01
>>> 01:00:00.0 +0100
>>> +++ linux/drivers/staging/iio/adc/ad7923_core.c2013-01-05
>> [...]
>>> +
>>> +static int ad7923_read_raw(struct iio_dev *indio_dev,
>>> + struct iio_chan_spec const *chan,
>>> + int *val,
>>> + int *val2,
>>> + long m)
>>> +{
>>> +int ret;
>>> +struct ad7923_state *st = iio_priv(indio_dev);
>>> +
>>> +switch (m) {
>>> +case IIO_CHAN_INFO_RAW:
>>> +mutex_lock(_dev->mlock);
>>> +if (iio_buffer_enabled(indio_dev))
>>> +ret = -EBUSY;
>>> +else
>>> +ret = ad7923_scan_direct(st, chan->address);
>>> +mutex_unlock(_dev->mlock);
>>> +
>>> +if (ret < 0)
>>> +return ret;
>>> +if (chan->address == EXTRACT(ret, 12, 4)) {
>>> +*val = EXTRACT(ret, 0, 12);
>>> +*val2 = EXTRACT_PERCENT(*val, 12);
>> val2 is never used in the upper layers in this case.
> I don't understand what you mean.
Just drop the *val2 = ... line. It doesn't make any sense in this context. Also
make sure to remove the EXTRACT_PERCENT macro since it wont be used anymore.
> Again, this is copied from AD7298
>>
[...]
>>> +/**
>>> + * ad7923_update_scan_mode() setup the spi transfer buffer for the
>>> new scan mask
>>> + **/
>>> +int ad7923_update_scan_mode(struct iio_dev *indio_dev,
>>> +const unsigned long *active_scan_mask)
>>> +{
>>> +struct ad7923_state *st = iio_priv(indio_dev);
>>> +int i, cmd, channel;
>>> +int scan_count;
>>> +
>>> +/* Now compute overall size */
>>> +for (i = 0, channel = 0; i < AD7923_MAX_CHAN; i++)
>>> +if (test_bit(i, active_scan_mask))
>>> +channel = i;
>>> +
>>> +cmd = AD7923_WRITE_CR | AD7923_CODING | AD7923_RANGE |
>>> +AD7923_PM_MODE_WRITE(AD7923_PM_MODE_OPS) |
>>> +AD7923_SEQUENCE_WRITE(AD7923_SEQUENCE_ON) |
>>> +AD7923_CHANNEL_WRITE(channel);
>> Hm, ok this looks a bit strange. You lookup the first channel which is
>> selected
>> and then also sample all channels which come before it. E.g. if only
>> channel 2
>> is selected you sample channel 0, 1 and 2. In the trigger handler you
>> push the
>> buffer to the IIO core. But in your buffer you have the result of
>> channel 0 in
>> the position where IIO would expect channel 2.
>> I think it is better if you send a cmd for each channel that needs to be
>> samples. E.g.:
>>
>> if (for_each_set_bit(i, active_scan_mask, AD7923_MAX_CHAN)) {
>> cmd = AD7923_WRITE_CR | AD7923_CODING | AD7923_RANGE |
>> AD7923_PM_MODE_WRITE(AD7923_PM_MODE_OPS) |
>> AD7923_SEQUENCE_WRITE(AD7923_SEQUENCE_OFF) |
>> AD7923_CHANNEL_WRITE(i);
>> cmd <<= AD7923_SHIFT_REGISTER;
>> st->tx_buf[j++] = cpu_to_be16(cmd);
>> }
> Ok, here we are trying to use the sequence mode. But unlike the AD7298,
> here sequence mode is only able to go from channel 0 to a given channel.
> Hence the reason why we try to identify the highest requested channel,
> then we do a sequential read of all from 0
Re: [PATCH 2/5] staging: zcache: rename ramster to zcache
On Fri, Jan 18, 2013 at 01:24:24PM -0800, Dan Magenheimer wrote: > [V2: no code changes, patchset now generated via git format-patch -M] If you put these comments below the --- cut off line (together with the diffstat) then "git am" won't add them to the commit log. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmotm 2013-01-18-15-48 uploaded (sched/stats.c)
On 01/18/13 15:49, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2013-01-18-15-48 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > on i386 or x86_64: kernel/sched/stats.c:31:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmotm 2013-01-18-15-48 uploaded (ath9k)
On 01/18/13 15:49, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2013-01-18-15-48 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > on i386: drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_process_fft': drivers/net/wireless/ath/ath9k/recv.c:1117:2: error: implicit declaration of function 'ath_debug_send_fft_sample' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[6]: *** [drivers/net/wireless/ath/ath9k/recv.o] Error 1 -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix compilation warning
On 01/18/13 12:47, Cong Ding wrote: > Is this patch still queued or...? > > - cong ping. Can we get this patch or something similar merged, please? > On Wed, Dec 5, 2012 at 6:10 PM, Cong Ding wrote: >> the following compilation warning is caused by Commit-ID: >> c566e8e9e44b72b53091da20e2dedefc730f2ee2 >> >> kernel/sched/debug.c: In function ‘print_cfs_rq’: >> kernel/sched/debug.c:225:2: warning: format ‘%ld’ expects argument of type >> ‘long int’, but argument 4 has type ‘long long int’ [-Wformat] >> kernel/sched/debug.c:225:2: warning: format ‘%ld’ expects argument of type >> ‘long int’, but argument 3 has type ‘long long int’ [-Wformat] >> >> where function atomic64_read returns long long int, but %ld was used in the >> printf >> >> Signed-off-by: Cong Ding >> --- >> kernel/sched/debug.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c >> index 2cd3c1b..83ec463 100644 >> --- a/kernel/sched/debug.c >> +++ b/kernel/sched/debug.c >> @@ -222,7 +222,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct >> cfs_rq *cfs_rq) >> cfs_rq->runnable_load_avg); >> SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg", >> cfs_rq->blocked_load_avg); >> - SEQ_printf(m, " .%-30s: %ld\n", "tg_load_avg", >> + SEQ_printf(m, " .%-30s: %lld\n", "tg_load_avg", >> atomic64_read(_rq->tg->load_avg)); >> SEQ_printf(m, " .%-30s: %lld\n", "tg_load_contrib", >> cfs_rq->tg_load_contrib); >> -- -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/urgent] x86-32: Start out cr0 clean, disable paging before modifying cr3/4
Commit-ID: 021ef050fc092d5638e69868d126c18006ea7296 Gitweb: http://git.kernel.org/tip/021ef050fc092d5638e69868d126c18006ea7296 Author: H. Peter Anvin AuthorDate: Sat, 19 Jan 2013 10:29:37 -0800 Committer: H. Peter Anvin CommitDate: Sat, 19 Jan 2013 11:01:22 -0800 x86-32: Start out cr0 clean, disable paging before modifying cr3/4 Patch 5a5a51db78e x86-32: Start out eflags and cr4 clean ... made x86-32 match x86-64 in that we initialize %eflags and %cr4 from scratch. This broke OLPC XO-1.5, because the XO enters the kernel with paging enabled, which the kernel doesn't expect. Since we no longer support 386 (the source of most of the variability in %cr0 configuration), we can simply match further x86-64 and initialize %cr0 to a fixed value -- the one variable part remaining in %cr0 is for FPU control, but all that is handled later on in initialization; in particular, configuring %cr0 as if the FPU is present until proven otherwise is correct and necessary for the probe to work. To deal with the XO case sanely, explicitly disable paging in %cr0 before we muck with %cr3, %cr4 or EFER -- those operations are inherently unsafe with paging enabled. NOTE: There is still a lot of 386-related junk in head_32.S which we can and should get rid of, however, this is intended as a minimal fix whereas the cleanup can be deferred to the next merge window. Reported-by: Andres Salomon Tested-by: Daniel Drake Link: http://lkml.kernel.org/r/50fa0661.2060...@linux.intel.com Signed-off-by: H. Peter Anvin --- arch/x86/kernel/head_32.S | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S index 8e7f655..c8932c7 100644 --- a/arch/x86/kernel/head_32.S +++ b/arch/x86/kernel/head_32.S @@ -300,6 +300,12 @@ ENTRY(startup_32_smp) leal -__PAGE_OFFSET(%ecx),%esp default_entry: +#define CR0_STATE (X86_CR0_PE | X86_CR0_MP | X86_CR0_ET | \ +X86_CR0_NE | X86_CR0_WP | X86_CR0_AM | \ +X86_CR0_PG) + movl $(CR0_STATE & ~X86_CR0_PG),%eax + movl %eax,%cr0 + /* * New page tables may be in 4Mbyte page mode and may * be using the global pages. @@ -364,8 +370,7 @@ default_entry: */ movl $pa(initial_page_table), %eax movl %eax,%cr3 /* set the page table pointer.. */ - movl %cr0,%eax - orl $X86_CR0_PG,%eax + movl $CR0_STATE,%eax movl %eax,%cr0 /* ..and set paging (PG) bit */ ljmp $__BOOT_CS,$1f /* Clear prefetch and normalize %eip */ 1: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] bluetooth: btmrvl_sdio: look for sd8688 firmware in proper location
The firmware images are shared with libertas_sdio WiFi chip and used to be in
libertas/ subtree in linux-firmware. As btmrvl_sdio used to look into the
linux-firmware root, it ended up being unsuccessful. Since the firmware files
are not specific to the libertas hardware, they're being moved into mrvl/ now.
Signed-off-by: Lubomir Rintel
---
drivers/bluetooth/btmrvl_sdio.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 9959d4c..1cb5183 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -83,8 +83,8 @@ static const struct btmrvl_sdio_card_reg btmrvl_reg_87xx = {
};
static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
- .helper = "sd8688_helper.bin",
- .firmware = "sd8688.bin",
+ .helper = "mrvl/sd8688_helper.bin",
+ .firmware = "mrvl/sd8688.bin",
.reg= _reg_8688,
.sd_blksz_fw_dl = 64,
};
@@ -1185,7 +1185,7 @@ MODULE_AUTHOR("Marvell International Ltd.");
MODULE_DESCRIPTION("Marvell BT-over-SDIO driver ver " VERSION);
MODULE_VERSION(VERSION);
MODULE_LICENSE("GPL v2");
-MODULE_FIRMWARE("sd8688_helper.bin");
-MODULE_FIRMWARE("sd8688.bin");
+MODULE_FIRMWARE("mrvl/sd8688_helper.bin");
+MODULE_FIRMWARE("mrvl/sd8688.bin");
MODULE_FIRMWARE("mrvl/sd8787_uapsta.bin");
MODULE_FIRMWARE("mrvl/sd8797_uapsta.bin");
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
> Please find attached a debug log generated with your patch. > > I used the sata disk and two em28xx dvb sticks, no other usb devices, > no ethernet cable connected, tuners on saa716x-based card not used. > > What I can see in the log: a lot of coherent mappings from sata_mv > and orion_ehci, a few from mv643xx_eth, no other coherent mappings. > All coherent mappings are page aligned, some of them (from orion_ehci) > are not really small (as claimed in __alloc_from_pool). > > I don't believe in a memory leak. When I restart vdr (the application > utilizing the dvb sticks) then there is enough dma memory available > again. Hi Soeren We should be able to rule out a leak. Mount debugfg and then: while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep 60 ; done while you are capturing. See if the number goes down. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/33] 3.7.4-stable review
On Fri, Jan 18, 2013 at 6:16 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.7.4 release. > There are 33 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon Jan 21 01:01:55 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.7.4-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h Patches applied cleanly to 3.0.y, 3.4.y, and 3.7.y. Compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics Cross-compile tests: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y. mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/21] 3.4.27-stable review
On Fri, Jan 18, 2013 at 6:19 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.4.27 release. > There are 21 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon Jan 21 01:05:31 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.27-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.y, 3.4.y, and 3.7.y. Compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics Cross-compile tests: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y. mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/21] ntb_netdev: improve logging
On Sat, 2013-01-19 at 02:02 -0700, Jon Mason wrote:
> Improve driver logging to be more helpful
[]
> diff --git a/drivers/net/ntb_netdev.c b/drivers/net/ntb_netdev.c
[]
> @@ -408,6 +408,5 @@ static void __exit ntb_netdev_exit_module(void)
> {
> ntb_unregister_client(_netdev_client);
> ntb_unregister_client_dev(KBUILD_MODNAME);
> - pr_info("%s: Driver removed\n", KBUILD_MODNAME);
It's almost always true that using
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
before any #include
and changing all pr_( uses from
pr_("s: etc...", KBUiLD_MODNAME, ...)
to
pr_("etc...", ...)
produces overall smaller object code.
That's even more likely for 64 bit compiled code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/16] 3.0.60-stable review
On Fri, Jan 18, 2013 at 6:21 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.0.60 release. > There are 16 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon Jan 21 01:20:05 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.60-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.y, 3.4.y, and 3.7.y. Compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics Cross-compile tests: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y. mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANN] rel-html HTML5 release page generator for Linux and friends
I had to write an HTML5 release page generator [0] for compat-drivers [1] for its new shiny new home page on kernel.org. While working on it I got a feature request to try to support any project, so I generalized the tool for any FOSS project. It currently supports parsing releases for the Linux kernel, compat-drivers, iw, crda, hostapd should any of these projects like it for its releases page. I'm happy to make the tool's first release now that it actually infers releases so there is no need to update the project configuration file when a new release is made, it will infer releases based on some supplied hints and naked index release URLs. Example output of what releases look like: http://drvbp1.linux-foundation.org/~mcgrof/rel-html/ Patches / feedback welcomed. [0] git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/rel-html.git [1] https://backports.wiki.kernel.org/ Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] power: bq27x00_battery: Export all battery registers via sysfs
On Saturday 19 January 2013 15:01:43 Pali Rohár wrote:
> bq27xxx batteries have a lot of properties, more than
> power_supply interface. Some of them can be usefull for
> userspace applications (like CI bit) but does not make sense
> to add bq specified property to power_supply interface. When
> bq27x00_battery is not loaded userspace application (like
> i2cget) can use /dev/i2c-* interface for raw access. But when
> kernel module is attached to i2c device, userspace
> applications cannot access it via /dev/i2c-*. Also it is not
> usefull for userspace to unload module before reading values
> form /dev/i2c-* and then load it again.
>
> This patch exporting all battery registers to sysfs entry
> "registers" in battery power_supply directory. Format is
> "register=value" on separate line. Because length of
> registers are different for each bq battery more for loops
> are needed.
>
> Signed-off-by: Pali Rohár
> ---
> drivers/power/bq27x00_battery.c | 98
> +-- 1 file changed, 95
> insertions(+), 3 deletions(-)
>
Opps, this patch causing null ptr derefernce. Here is new fixed version:
diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c
index 7087d0d..4f54ad3 100644
--- a/drivers/power/bq27x00_battery.c
+++ b/drivers/power/bq27x00_battery.c
@@ -690,6 +690,90 @@ static void bq27x00_external_power_changed(struct
power_supply *psy)
schedule_delayed_work(>work, 0);
}
+/* code for register device access via sysfs */
+
+static ssize_t bq27x00_battery_sysfs_print_reg(struct bq27x00_device_info *di,
+ u8 reg, bool single, char *buf)
+{
+ int ret = bq27x00_read(di, reg, single);
+ if (ret < 0)
+ return sprintf(buf, "%#.2x=error %d\n", reg, ret);
+ else
+ return sprintf(buf, "%#.2x=%#.2x\n", reg, ret);
+}
+
+static ssize_t bq27x00_battery_sysfs_show_registers(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct power_supply *psy = dev_get_drvdata(dev);
+ struct bq27x00_device_info *di = container_of(psy,
+ struct bq27x00_device_info,
+ bat);
+ u8 reg;
+ ssize_t ret = 0;
+
+ switch (di->chip) {
+
+ case BQ27000:
+ for (reg=0x00; reg<=0x01; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ for (reg=0x02; reg<=0x08; reg+=2)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
buf+ret);
+ for (reg=0x0A; reg<=0x0B; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ for (reg=0x0C; reg<=0x2A; reg+=2)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
buf+ret);
+ for (reg=0x2C; reg<=0x7F; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ break;
+
+ case BQ27500:
+ for (reg=0x00; reg<=0x2C; reg+=2)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
buf+ret);
+ for (reg=0x2E; reg<=0x3B; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ for (reg=0x3C; reg<=0x3C; reg+=2)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
buf+ret);
+ for (reg=0x3E; reg<=0x7F; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ break;
+
+ case BQ27425:
+ for (reg=0x00; reg<=0x3C; reg+=2)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
buf+ret);
+ for (reg=0x3E; reg<=0x7F; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ break;
+
+ }
+
+ return ret;
+}
+
+static DEVICE_ATTR(registers, S_IRUGO,
+ bq27x00_battery_sysfs_show_registers, NULL);
+
+static struct attribute *bq27x00_battery_sysfs_attributes[] = {
+ _attr_registers.attr,
+ NULL,
+};
+
+static const struct attribute_group bq27x00_battery_sysfs_attr_group = {
+ .attrs = bq27x00_battery_sysfs_attributes,
+};
+
+static int bq27x00_battery_sysfs_init(struct bq27x00_device_info *di)
+{
+ return sysfs_create_group(>bat.dev->kobj,
+ _battery_sysfs_attr_group);
+}
+
+static void bq27x00_battery_sysfs_exit(struct bq27x00_device_info *di)
+{
+ sysfs_remove_group(>bat.dev->kobj,
+ _battery_sysfs_attr_group);
+}
+
static int bq27x00_powersupply_init(struct bq27x00_device_info *di)
{
int ret;
@@ -711,6 +795,15 @@ static int bq27x00_powersupply_init(struct
bq27x00_device_info *di)
ret = power_supply_register(di->dev, >bat);
Re: [PATCH v7 3/4] block: implement runtime pm strategy
On Sat, 19 Jan 2013, Aaron Lu wrote: > > Okay. I think you can add (in parentheses) that in most cases drivers > > should call the routine before any I/O has taken place. > > The reason I put it that way is, in patch 4, the blk_pm_runtime_init is > called after a request is executed(scsi_probe_lun). I do not want people > get confused by the comments for blk_pm_runtime_init and the example > code in patch 4 where we didn't follow it :-) Right. > Considering ODD's use case, I was thinking of moving the > blk_pm_runtime_init call to sd.c, as sr will not use request based auto > suspend. Probably right before we decrease usage count for the device in > sd_probe_async. What do you think? That makes sense. But then you should review the changes in scsi_pm.c to make sure they will work okay for devices that aren't using block-layer runtime PM. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: btrfs userspace question - where's the utility to dump/restore?
On Thu, 17 Jan 2013 22:18:19 +, Hugo Mills said: > On Thu, Jan 17, 2013 at 03:05:35PM -0500, Valdis Kletnieks wrote: > > So I'm looking at playing with btrfs, and I start looking at the > > userspace pieces I'll need. What I can't find is an equivalent > > of the ext[34] "dump/restore" package to dump data to an external > > backup device. Is 'tar cf --acls --selinux --xattrs /external/fs.dump' > > as good as it gets, or is something else recommended? > >tar doesn't handle reflinks(+), so the above won't quite give you a > complete duplicate. In the btrfs tool, there's send/receive, which > should(*) be sufficient to deal with reflinks. So I decided to try it out on the filesystem that I stash all my music (mostly because I can survive without that filesystem if I trash it, and I have a known good backup). Apparently, send/receive isn't in the manpage, which is why I didn't see it. Fortunately, there's --help [~] btrfs send --help usage: btrfs send btrfs send [-v] [-i ] [-p ] Send the subvolume to stdout. [~] btrfs send -v /mp3 > /disk2/backups/mp3.btrfs ERROR: /mp3 is not read-only. [~] mount -o remount,ro /mp3 [~] btrfs send -v /mp3 >| /disk2/backups/mp3.btrfs ERROR: /mp3 is not read-only. Bah. Obviously this isn't anywhere near as easy as it is for ext4. /me wanders off to find more caffeine... pgp3mpfmuo5PP.pgp Description: PGP signature
Re: Null pointer dereference when accessing /dev/dsp1 with USB speakers
Hi! > > I have USB speakers > > > > Bus 004 Device 002: ID 04fa:4201 Dallas Semiconductor DS4201 Audio DAC > > > > ... which make problems again > > (https://lkml.org/lkml/2008/3/20/274). They refuse to produce sound, > > so I updated to 3.8.0-rc2 in hope that would help... and tried testing > > them by "cat /bin/bash > /dev/dsp1". Instant crash :-(. > > > > I guess this will happen in more than one config...? > > This Oops should have been fixed recently. Please try 3.8-rc4. > > commit 31be5425d795585251a3ee970319c37643e0cda2 > ALSA: usb-audio: Fix NULL dereference by access to non-existing > substream It is fixed in 3.8-rc4. But... I still get this: (it happened at least once with 3.8-rc2 and once with 3.8-rc4). > > Jan 18 21:23:00 amd kernel: Slab corruption (Tainted: GW ): > > size-128 start=edd71b40, len=128 > > Jan 18 21:23:00 amd kernel: 070: 6b 6b 6b 6b 6b 6b 6b 6b 00 6b 6b 6b > > 6b 6b 6b a5 .kk. > > Jan 18 21:23:00 amd kernel: Prev obj: start=edd71ac0, len=128 > > Jan 18 21:23:00 amd kernel: 000: 00 7f e9 e9 c8 2f 40 f0 00 00 00 00 > > 00 00 00 00 ./@. > > Jan 18 21:23:00 amd kernel: 010: 00 00 00 00 00 00 00 00 00 6c 94 e9 > > 00 00 00 00 .l.. > > Jan 18 21:23:00 amd kernel: Next obj: start=edd71bc0, len=128 > > Jan 18 21:23:00 amd kernel: 000: 40 12 d7 ed 40 11 d7 ed 02 00 00 00 > > 02 00 00 00 @...@... > > Jan 18 21:23:00 amd kernel: 010: 00 00 00 00 00 00 00 00 20 53 77 69 > > 74 63 68 00 Switch. > > Jan 18 21:23:00 amd kernel: 8:0: cannot get min/max values for control > > 5 (id 8) > > Jan 18 21:23:00 amd kernel: 8:0: cannot get min/max values for control > > 6 (id 8) > > Jan 18 21:23:00 amd kernel: 8:0: cannot get min/max values for control > > 1 (id 8) > > Jan 18 21:23:00 amd kernel: 8:0: cannot get min/max values for control > > 2 (id 8) > > Jan 18 21:23:00 amd kernel: usb 4-1: adding 4-1:1.1 (config #1, > > interface 1) > > Jan 18 21:23:00 amd kernel: hub 4-0:1.0: state 7 ports 2 chg evt > > 0002 Any ideas? Any similar reports? (Hmm, and maybe "SLAB corruption" messages should have higher severity? KERN_ALERT or something, so that it is broadcast to all consoles?) Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC Patch v1 00/31] Synopsys ARC Linux kernel Port
Hi! > >>> Ok, plus there's already computing standard called "arc". > >>> > >>> https://www.linux-mips.org/wiki/ARC > >>> > >>> What about calling the architecture "sarc" or "syarc" ? > >> I think it would be best use of everybody's time if you could focus on > >> the technical content of the port rather than the name. It has been like > >> that for +10 years and I don't intend to make the kernel port name > >> different from THE arch name itself. > > Yeah, and it is best use of reviewers time to confuse them with > > one-letter difference to very popular architecture... and use three > > letter acronym that was already taken. > > > > In this state, I hope your port never gets merged. Yes, I got used to > > do cd a/ar. > > Although I really don't want to spend time arguing with you but still .. > if > you had a neighbor with same name as your friend your strategy most likely > would > be to force one of them to change names - kind of seems funny and > stupid. Yeah, imagine creating "/bin/mr" that would be du equivalent. How many people would delete their files by mistake? > Having said that, despite all the ranting so far, you've not managed to > comment on > a single line of the actual code, which is more funny and stupid. So Yeah, you tricked me into reviewing your code. No, I will not do more reviews for you. Yes, I bet I'm not the only one, and I bet that mistake will happen about once per developer. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux 3.8-rc4
> -Original Message- > From: Shuah Khan [mailto:shuahk...@gmail.com] > Sent: Friday, January 18, 2013 7:40 PM > To: Linus Torvalds; Deucher, Alexander > Cc: Linux Kernel Mailing List > Subject: Re: Linux 3.8-rc4 > > On Fri, Jan 18, 2013 at 3:37 PM, Shuah Khan wrote: > > On Fri, Jan 18, 2013 at 10:51 AM, Shuah Khan > wrote: > > > > > ok. I bisected the DMAR faults and it points to the following commit: > > > > 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb > > > > This commit as I recall, fixed the crash problem I was seeing back in > > 3.8-rc1. Reverting to see if crash problem reappears. > > Confirming that with this commit reverted crash problem re-appeared. > With this commit, DMAR faults show up. I'm not quite sure what's going on with your system. At this point it's probably best to just disable the DMA ring on these cards until we sort out what's going on. The attached patch disables the use of the DMA ring. Let me know if it fixes the issues you are seeing. Alex disable_dma_ring_on_6xx.diff Description: disable_dma_ring_on_6xx.diff
[PATCH] perf evsel: fix NULL pointer deference when evsel->counts is NULL
From: Colin Ian King __perf_evsel__read_on_cpu() only bails out with -ENOMEM if evsel->counts is NULL and perf_evsel__alloc_counts() has returned an error. If perf_evsel__alloc_counts() does not return an error we get an NULL pointer deference on evsel->counts->cpu[cpu] if evsel->counts is NULL. Signed-off-by: Colin Ian King --- tools/perf/util/evsel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 1b16dd1..93acd06 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -640,7 +640,7 @@ int __perf_evsel__read_on_cpu(struct perf_evsel *evsel, if (FD(evsel, cpu, thread) < 0) return -EINVAL; - if (evsel->counts == NULL && perf_evsel__alloc_counts(evsel, cpu + 1) < 0) + if (evsel->counts == NULL || perf_evsel__alloc_counts(evsel, cpu + 1) < 0) return -ENOMEM; if (readn(FD(evsel, cpu, thread), , nv * sizeof(u64)) < 0) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Linux - AMD SB950 USB Regression
On Sat, Jan 19, 2013 at 03:47:53PM +0100, dAgeCKo wrote: > I can't try the solution you are giving since I can't (and don't want > to try to) downgrade my BIOS. I don't think I said that. Here's what I actually said: >> So dAgeCKo, that would be another thing you could do: try enabling >> the IOMMU in the BIOS and the above CONFIG option and the issue would >> be fixed too. IOW, you enter the BIOS, go to "NB settings" or similar and set IOMMU to Auto/Enabled. Provided you have an IOMMU but you should have that on this chipset. Then, you enable CONFIG_AMD_IOMMU in your kernel and done: the kernel uses the IOMMU hardware instead of the GART. That's it, no need for any BIOS up-/downgrading. > Another important thing you might be interested in is that not only > my USB 2 weren't working. My mainboard ethernet wasn't working to > (and was resolved with the BIOS upgrade too). The ethernet chip is: > > 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) > > I don't know if that can be related to what you are saying. It could be, my nic kept resetting and once got an xmit queue timeout so it could very well be related. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i915-related and general system freezes with specific kernel config // IOMMU
On Sat, Jan 19, 2013 at 5:26 PM, Mihai Moldovan wrote: > The current patch errors out on my while compiling as quirk_iommu_rwbf is not > yet defined at that place. Oops, attached an old patch, updated one should work better. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i915-related and general system freezes with specific kernel config // IOMMU
* On 19.01.2013 05:13 PM, Mihai Moldovan wrote: > * On 19.01.2013 02:27 PM, Daniel Vetter wrote: >> You have a gen4.5 chipset which is known to be utterly broken for >> IOMMU+intel gpu. > Nice description for what I'm seeing. ;) > > After some more hours of uptime I'm inclined to say, that "intel_iommu=off > iommu=off" fixes my random freezes as well. > Alas, the USB and PCI(e) problems are still around, but I could test > recompiling > 3.7.2 with Intel IOMMU turned off completely in the kernel config. > Interestingly, my 3.0.2 kernel which worked fine for so long doesn't even > *have* > support for VT-d/Intel IOMMU. This could explain why I wasn't bit by those > problems on all previous versions. > > >> [...] and we've never added the proper >> quirks. See https://bugzilla.kernel.org/show_bug.cgi?id=51921 for a >> proposed patch to fix this (i.e. automatically set >> intel_iommu=igfx_off for affected platfroms). Testing highly welcome. > From a quick glance, I don't think this patch will work as-is, my PCI ID 2e12 > is > missing. > [...] Which of course will work, as 2e10 is my DRAM controller as reported by lspci, sorry. But, shouldn't the "DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2eXX, quirk_iommu_rwbf);" calls be rather " DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_g4x_gfx);" ? The current patch errors out on my while compiling as quirk_iommu_rwbf is not yet defined at that place. smime.p7s Description: S/MIME Cryptographic Signature
Re: i915-related and general system freezes with specific kernel config // IOMMU
On Sat, Jan 19, 2013 at 5:13 PM, Mihai Moldovan wrote: >> [...] and we've never added the proper >> quirks. See https://bugzilla.kernel.org/show_bug.cgi?id=51921 for a >> proposed patch to fix this (i.e. automatically set >> intel_iommu=igfx_off for affected platfroms). Testing highly welcome. > > From a quick glance, I don't think this patch will work as-is, my PCI ID 2e12 > is > missing. > I'll add it to the relevant section. The quirk matches your pci host bridge, which should have id 2e10, not the gfx, which has id 2e12. > But even if it worked, I'd still have the "box freezes randomly" issue (mostly > within 5 to 60 minutes of uptime). :( > The only way to get rid of this is disabling Intel IOMMU as a whole via kernel > parameters intel_iommu=off iommu=off. Hm, can you try enabling the related iommu quirk: diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index b9d0911..e834395 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -4251,6 +4251,7 @@ static void quirk_iommu_rwbf(struct pci_dev *dev) } DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_rwbf); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_rwbf); #define GGC 0x52 #define GGC_MEMORY_SIZE_MASK (0xf << 8) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
On Thu, Jan 17, 2013 at 08:26:45PM +, Arnd Bergmann wrote: > On Thursday 17 January 2013, Soeren Moch wrote: > > On 17.01.2013 11:49, Arnd Bergmann wrote: > > > On Wednesday 16 January 2013, Soeren Moch wrote: > > I will see what I can do here. Is there an easy way to track the buffer > > usage without having to wait for complete exhaustion? > > >>> > > >>> DMA_API_DEBUG > > >> > > >> OK, maybe I can try this. I tried this. Not what i expected. We have at least one problem with the ethernet driver: WARNING: at lib/dma-debug.c:933 check_unmap+0x4b8/0x8a8() mv643xx_eth_port mv643xx_eth_port.0: DMA-API: device driver failed to check map error[device address=0x1f22be00] [size=1536 bytes] [mapped as single] Modules linked in: [] (unwind_backtrace+0x0/0xf4) from [] (warn_slowpath_common+0x4c/0x64) [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_fmt+0x30/0x40) [] (warn_slowpath_fmt+0x30/0x40) from [] (check_unmap+0x4b8/0x8a8) [] (check_unmap+0x4b8/0x8a8) from [] (debug_dma_unmap_page+0x8c/0x98) [] (debug_dma_unmap_page+0x8c/0x98) from [] (mv643xx_eth_poll+0x630/0x800) [] (mv643xx_eth_poll+0x630/0x800) from [] (net_rx_action+0xcc/0x1d4) [] (net_rx_action+0xcc/0x1d4) from [] (__do_softirq+0xa8/0x170) [] (__do_softirq+0xa8/0x170) from [] (do_softirq+0x5c/0x6c) [] (do_softirq+0x5c/0x6c) from [] (local_bh_enable+0xcc/0xdc) [] (local_bh_enable+0xcc/0xdc) from [] (ip_finish_output+0x1c8/0x39c) [] (ip_finish_output+0x1c8/0x39c) from [] (ip_local_out+0x28/0x2c) [] (ip_local_out+0x28/0x2c) from [] (ip_queue_xmit+0x118/0x338) [] (ip_queue_xmit+0x118/0x338) from [] (tcp_transmit_skb+0x3fc/0x8e4) [] (tcp_transmit_skb+0x3fc/0x8e4) from [] (tcp_write_xmit+0x228/0xb08) [] (tcp_write_xmit+0x228/0xb08) from [] (__tcp_push_pending_frames+0x30/0x9c) [] (__tcp_push_pending_frames+0x30/0x9c) from [] (tcp_sendmsg+0x158/0xdc4) [] (tcp_sendmsg+0x158/0xdc4) from [] (inet_sendmsg+0x38/0x74) [] (inet_sendmsg+0x38/0x74) from [] (sock_aio_write+0x12c/0x138) [] (sock_aio_write+0x12c/0x138) from [] (do_sync_write+0xa0/0xd0) [] (do_sync_write+0xa0/0xd0) from [] (vfs_write+0x13c/0x144) [] (vfs_write+0x13c/0x144) from [] (sys_write+0x44/0x70) [] (sys_write+0x44/0x70) from [] (ret_fast_syscall+0x0/0x2c) ---[ end trace b75faa8779652e63 ]--- I'm getting about 4 errors reported a second from the ethernet driver. Before i look at issues with em28xx i will first try to get the noise from the ethernet driver sorted out. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i915-related and general system freezes with specific kernel config // IOMMU
* On 19.01.2013 02:27 PM, Daniel Vetter wrote: > You have a gen4.5 chipset which is known to be utterly broken for > IOMMU+intel gpu. Nice description for what I'm seeing. ;) After some more hours of uptime I'm inclined to say, that "intel_iommu=off iommu=off" fixes my random freezes as well. Alas, the USB and PCI(e) problems are still around, but I could test recompiling 3.7.2 with Intel IOMMU turned off completely in the kernel config. Interestingly, my 3.0.2 kernel which worked fine for so long doesn't even *have* support for VT-d/Intel IOMMU. This could explain why I wasn't bit by those problems on all previous versions. > [...] and we've never added the proper > quirks. See https://bugzilla.kernel.org/show_bug.cgi?id=51921 for a > proposed patch to fix this (i.e. automatically set > intel_iommu=igfx_off for affected platfroms). Testing highly welcome. From a quick glance, I don't think this patch will work as-is, my PCI ID 2e12 is missing. I'll add it to the relevant section. But even if it worked, I'd still have the "box freezes randomly" issue (mostly within 5 to 60 minutes of uptime). :( The only way to get rid of this is disabling Intel IOMMU as a whole via kernel parameters intel_iommu=off iommu=off. Anyway, I'll give it a try. Best regards, Mihai smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] tty: Correct tty buffer flush.
On Sat, Jan 19, 2013 at 4:12 PM, Sedat Dilek wrote:
> On Sat, Jan 19, 2013 at 3:16 PM, Ilya Zykov wrote:
>> The root of problem is carelessly zeroing pointer(in function
>> __tty_buffer_flush()),
>> when another thread can use it. It can be cause of "NULL pointer
>> dereference".
>> Main idea of the patch, this is never free last (struct tty_buffer) in the
>> active buffer.
>> Only flush the data for ldisc(buf->head->read = buf->head->commit).
>> At that moment driver can collect(write) data in buffer without conflict.
>> It is repeat behavior of flush_to_ldisc(), only without feeding data to
>> ldisc.
>>
>> Also revert:
>> commit c56a00a165712fd73081f40044b1e64407bb1875
>> tty: hold lock across tty buffer finding and buffer filling
>> In order to delete the unneeded locks any more.
>>
>> Signed-off-by: Ilya Zykov
>>
>
> I have tested your patch on top of Linux-Next (next-20130118) plus my
> own patchset (see file attachments)!
>
> [ TESTCASE ]
>
> # grep CONFIG_PM_DEBUG /boot/config-$(uname -r)
> CONFIG_PM_DEBUG=y
>
> # echo "freezer" > /sys/power/pm_test
>
> # cat /sys/power/pm_test
> none core processors platform devices [freezer]
>
> # echo mem > /sys/power/state && sleep 1 <--- 1st S/R: OK
>
> # echo mem > /sys/power/state && sleep 1 <--- 2nd S/R: OK, but caused
> a call-trace (see above)!
>
> [ /TESTCASE ]
>
> Unfortunately, I get now a different call-trace on the 2nd freezer/pm-test...
>
> +[ 368.891613] PM: Preparing system for mem sleep
> +[ 373.886722] Freezing user space processes ... (elapsed 0.01 seconds) done.
> +[ 373.902741] Freezing remaining freezable tasks ...
> +[ 393.904587] Freezing of tasks failed after 20.01 seconds (1 tasks
> refusing to freeze, wq_busy=0):
> +[ 393.904714] jbd2/loop0-8D 0003 0 304 2
> 0x
> +[ 393.904723] 880117525b68 0046
> 8801195d9400
> +[ 393.904731] 880117d74560 880117525fd8 880117525fd8
> 880117525fd8
> +[ 393.904738] 88004212c560 880117d74560 880117525b68
> 88011fad4738
> +[ 393.904745] Call Trace:
> +[ 393.904764] [] ? __wait_on_buffer+0x30/0x30
> +[ 393.904772] [] schedule+0x29/0x70
> +[ 393.904778] [] io_schedule+0x8f/0xd0
> +[ 393.904785] [] sleep_on_buffer+0xe/0x20
> +[ 393.904794] [] __wait_on_bit+0x5f/0x90
> +[ 393.904801] [] ? __wait_on_buffer+0x30/0x30
> +[ 393.904809] [] out_of_line_wait_on_bit+0x7c/0x90
> +[ 393.904817] [] ? autoremove_wake_function+0x40/0x40
> +[ 393.904824] [] __wait_on_buffer+0x2e/0x30
> +[ 393.904836] []
> jbd2_journal_commit_transaction+0xdef/0x1960
> +[ 393.904844] [] ? _raw_spin_lock_irqsave+0x2e/0x40
> +[ 393.904853] [] ? try_to_del_timer_sync+0x4f/0x70
> +[ 393.904859] [] kjournald2+0xb8/0x240
> +[ 393.904865] [] ? add_wait_queue+0x60/0x60
> +[ 393.904871] [] ? commit_timeout+0x10/0x10
> +[ 393.904877] [] kthread+0xc0/0xd0
> +[ 393.904883] [] ? flush_kthread_worker+0xb0/0xb0
> +[ 393.904889] [] ret_from_fork+0x7c/0xb0
> +[ 393.904894] [] ? flush_kthread_worker+0xb0/0xb0
> +[ 393.904972]
> +[ 393.904975] Restarting kernel threads ... done.
> +[ 393.905163] Restarting tasks ... done.
> +[ 393.914283] video LNXVIDEO:00: Restoring backlight state
>
> If this ring one or more bells to you let me know!
>
> Please, have a look at the file attachments!
> Thanks.
>
> Hope this helps us to track the problem!
>
I turned on...
CONFIG_EXT4_DEBUG=y
CONFIG_JBD2_DEBUG=y
...to see more light in the dark.
- Sedat -
> - Sedat -
>
>> ---
>> drivers/tty/tty_buffer.c | 92
>> +++---
>> 1 files changed, 22 insertions(+), 70 deletions(-)
>>
>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>> index d6969f6..61ec4dd 100644
>> --- a/drivers/tty/tty_buffer.c
>> +++ b/drivers/tty/tty_buffer.c
>> @@ -119,11 +119,14 @@ static void __tty_buffer_flush(struct tty_port *port)
>> struct tty_bufhead *buf = >buf;
>> struct tty_buffer *thead;
>>
>> - while ((thead = buf->head) != NULL) {
>> - buf->head = thead->next;
>> - tty_buffer_free(port, thead);
>> + if (unlikely(buf->head == NULL))
>> + return;
>> + while ((thead = buf->head->next) != NULL) {
>> + tty_buffer_free(port, buf->head);
>> + buf->head = thead;
>> }
>> - buf->tail = NULL;
>> + WARN_ON(buf->head != buf->tail);
>> + buf->head->read = buf->head->commit;
>> }
>>
>> /**
>> @@ -194,19 +197,22 @@ static struct tty_buffer *tty_buffer_find(struct
>> tty_port *port, size_t size)
>>have queued and recycle that ? */
>> }
>> /**
>> - * __tty_buffer_request_room - grow tty buffer if
>> needed
>> + * tty_buffer_request_room - grow tty buffer if needed
>> * @tty: tty structure
>> * @size: size desired
>> *
>> * Make at least size bytes of linear space available
Re: IPsec AH use of ahash
On Sat, 2013-01-19 at 05:30 -0500, Tom St Denis wrote: > As someone who maintained (and I mean that in all senses not just > applied patches) OSS projects while working full time and still trying > to have a life I get it. That said I never turned away patches solely > on "style" issues. At the same time you should look at the size and > scope of the patches I'm talking about. It took me all of less than > an hour to develop and less than a couple of hours to give it a run to > see if it works correctly [talking about the CMAC patch]. > > This *should* be a no-brainer to apply. > Again, if its a no-brainer, the patch should be perfect, so that our brains can cope with the hard to review patches, and hard to debug problems. A maintainer is not a machine doing mechanical work Every time we have to ask you another round, its a lost of time for everybody. Really if you can not understand that, thats too bad. > For those of us who do Kernel development during business hours it's > hard to justify the work when the path to mainline is convoluted and > landmined. Thousands of contributors just did it very well. You might read a bit Documentation/SubmittingPatches vi +263 Documentation/SubmittingPatches This is a bit outdated, as obviously Linus is not the guy most contributors are dealing with. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LIO - the broken iSCSI target implementation
On Fri, Jan 18, 2013 at 9:21 PM, wrote: > Please don't start another "SCST Vs. LIO" holy war here. We all know why LIO > belongs to Linux kernel and SCST does not. SCST is not familiar to me. Does this mean that SCST is competition for the StarWind products but LIO not ? Fubo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] btrfs: fix potential null pointer dereference bug
The bug happens when rb_node == NULL. It causes variable node to be NULL and
then the NULL pointer is dereferenced this line:
BUG_ON((struct btrfs_root *)node->data != root);
Based on my analysis, function tree_search should not return NULL to variable
rb_node in this case (otherwise here has to be something unknown thing wrong),
so I replace "if (rb_node)" with UG_ON(!rb_node).
Signed-off-by: Cong Ding
---
fs/btrfs/relocation.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 17c306b..d674671 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1263,10 +1263,11 @@ static int __update_reloc_root(struct btrfs_root *root,
int del)
spin_lock(>reloc_root_tree.lock);
rb_node = tree_search(>reloc_root_tree.rb_root,
root->commit_root->start);
- if (rb_node) {
- node = rb_entry(rb_node, struct mapping_node, rb_node);
- rb_erase(>rb_node, >reloc_root_tree.rb_root);
- }
+ BUG_ON(!rb_node);
+
+ node = rb_entry(rb_node, struct mapping_node, rb_node);
+ rb_erase(>rb_node, >reloc_root_tree.rb_root);
+
spin_unlock(>reloc_root_tree.lock);
BUG_ON((struct btrfs_root *)node->data != root);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IIO ADC support for AD7923
Hi Lars,
Sorry to respond so late, I've been very busy lately.
Please see answers/questions below
Main point is that our driver is mainly copied and adapted from AD7298
driver, and your comments are on things that we have not modified from
AD7298, so what should we do really ?
We are a bit new comers in Kernel Development, so thanks for your help.
Christophe
Le 08/01/2013 11:27, Lars-Peter Clausen a écrit :
On 01/08/2013 09:42 AM, Christophe Leroy wrote:
This patch adds support for Analog Devices AD7923 ADC in the IIO Subsystem.
Signed-off-by: Patrick Vasseur
Signed-off-by: Christophe Leroy
Hi,
Thanks for the driver, looks pretty good. Some comments inline.
- Lars
diff -uN linux-3.7.1/drivers/staging/iio/adc/Kconfig
linux/drivers/staging/iio/adc/Kconfig
--- linux-3.7.1/drivers/staging/iio/adc/Kconfig 2012-12-17 20:14:54.0
+0100
+++ linux/drivers/staging/iio/adc/Kconfig 2012-12-13 19:52:10.0
+0100
New IIO drivers should not be added to staging, unless there is a very good
reason. Since this driver does not have any major issues it should directly go
into drivers/iio/
Our driver is based on AD7298 driver, which is today in staging. Should
we put ours in drivers/iio/ directly anyway ?
[...]
diff -uN linux-3.7.1/drivers/staging/iio/adc/ad7923.h
linux/drivers/staging/iio/adc/ad7923.h
--- linux-3.7.1/drivers/staging/iio/adc/ad7923.h1970-01-01
01:00:00.0 +0100
+++ linux/drivers/staging/iio/adc/ad7923.h 2013-01-05 17:53:53.0
+0100
@@ -0,0 +1,72 @@
+/*
+ * AD7923 SPI ADC driver
+ *
+ * Copyright 2011 Analog Devices Inc (from AD7298 Driver)
+ * Copyright 2012 CS Systemes d'Information
+ *
+ * Licensed under the GPL-2 or later.
+ */
+#ifndef IIO_ADC_AD7923_H_
+#define IIO_ADC_AD7923_H_
+
+#define AD7923_WRITE_CR(1 << 11) /* write control register */
+#define AD7923_RANGE (1 << 1) /* range to REFin */
+#define AD7923_CODING (1 << 0) /* coding is straight binary */
+#define AD7923_PM_MODE_AS (1) /* auto shutdown */
+#define AD7923_PM_MODE_FS (2) /* full shutdown */
+#define AD7923_PM_MODE_OPS (3) /* normal operation */
+#define AD7923_CHANNEL_0 (0) /* analog input 0 */
+#define AD7923_CHANNEL_1 (1) /* analog input 1 */
+#define AD7923_CHANNEL_2 (2) /* analog input 2 */
+#define AD7923_CHANNEL_3 (3) /* analog input 3 */
+#define AD7923_SEQUENCE_OFF(0) /* no sequence fonction */
+#define AD7923_SEQUENCE_PROTECT(2) /* no interrupt write
cycle */
+#define AD7923_SEQUENCE_ON (3) /* continuous sequence */
+
+#define AD7923_MAX_CHAN4
+
+#define AD7923_PM_MODE_WRITE(mode) (mode << 4) /* write mode */
+#define AD7923_CHANNEL_WRITE(channel) (channel << 6)/* write channel */
+#define AD7923_SEQUENCE_WRITE(sequence)(((sequence & 1) << 3) \
+ + ((sequence & 2) << 9))
+ /* write sequence fonction */
+/* left shift for CR : bit 11 transmit in first */
+#define AD7923_SHIFT_REGISTER 4
+
+/* val = value, dec = left shift, bits = number of bits of the mask */
+#define EXTRACT(val, dec, bits)((val >> dec) & ((1 << bits) -
1))
+/* val = value, bits = number of bits of the original value */
+#define EXTRACT_PERCENT(val, bits) (((val + 1) * 100) >> bits)
+
+struct ad7923_state {
+ struct spi_device *spi;
+ struct regulator*reg;
+ struct spi_transfer ring_xfer[6];
+ struct spi_transfer scan_single_xfer[2];
+ struct spi_message ring_msg;
+ struct spi_message scan_single_msg;
+ /*
+* DMA (thus cache coherency maintenance) requires the
+* transfer buffers to live in their own cache lines.
+*/
+ unsigned short rx_buf[4] cacheline_aligned;
+ unsigned short tx_buf[2];
both buffers should of type __be16
This part is copied unmodified from AD7298. Should we modify it ?
+};
+
+#ifdef CONFIG_IIO_BUFFER
+int ad7923_register_ring_funcs_and_init(struct iio_dev *indio_dev);
+void ad7923_ring_cleanup(struct iio_dev *indio_dev);
+int ad7923_update_scan_mode(struct iio_dev *indio_dev,
+ const unsigned long *active_scan_mask);
+#else /* CONFIG_IIO_BUFFER */
+static inline int
+ad7923_register_ring_funcs_and_init(struct iio_dev *indio_dev)
+{
+ return 0;
+}
+static inline void ad7923_ring_cleanup(struct iio_dev *indio_dev)
+{
+}
+#define ad7923_update_scan_mode NULL
+#endif /* CONFIG_IIO_BUFFER */
+#endif /* IIO_ADC_AD7923_H_ */
diff -uN linux-3.7.1/drivers/staging/iio/adc/ad7923_core.c
linux/drivers/staging/iio/adc/ad7923_core.c
--- linux-3.7.1/drivers/staging/iio/adc/ad7923_core.c 1970-01-01
01:00:00.0
Re: [RFC PATCH v5 7/8] PCI/PCIe: add "pci=nopciehp" to disable PCIe native hotplug
On Sat, Jan 19, 2013 at 09:56:24AM +0800, Yijing Wang wrote: > 于 2013-01-19 1:35, Bjorn Helgaas 写道: > > On Fri, Jan 18, 2013 at 9:07 AM, Jiang Liu wrote: > >> If user specifies "pci=nopciehp" on kernel boot command line, OSPM > >> won't claim PCIe native hotplug service from firmware and no PCIe > >> port devices will be created for PCIe native hotplug service. > > > > Why do we need this option? > > > > If I understand correctly, there are machines where it *looks* like we > > should use pciehp, but pciehp doesn't work because we don't get the > > interrupts we expect. On those machines, we have to use acpiphp > > instead. It seems like many Dell XPS laptops have this issue with > > ExpressCard slots, e.g., > > https://bugzilla.kernel.org/show_bug.cgi?id=40802 . > > What about use modprobe pciehp pciehp_poll_mode=1? > If just cannot receive the interrupt, maybe this module parameter will fix it. You can't add a new option that you now force hardware that was working with a different module to now define and use. It needs to be "automatic". > > If you want "pci=nopciehp" as a way for users to deal with this > > problem by forcing the use of acpiphp, I object. Windows manages to > > make these slots work without having users do anything special, so we > > should be able to do it, too. > > In fact, pcie native hotplug may not be implemented perfectly, Oh, we know that is true, it's the problem here. Fixing BIOSes would be nice, but we can't do that :( greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Linux - AMD SB950 USB Regression
Le 17/01/2013 22:36, Borislav Petkov a écrit : So, there seems to be some serious breakage with GART on SB9xx. I don't know whether this is the platform BIOS or the vendor BIOS causing it because the original bug reporter says he observes the issue on an MSI board and I'm experiencing this on my favourite bunch ASUS. So, if you use the GART as an IOMMU, i.e.: Jan 17 22:08:15 pd kernel: [0.924063] PCI-DMA: using GART IOMMU. Jan 17 22:08:15 pd kernel: [0.924120] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture USB ports start choking like this: Jan 17 22:08:15 pd kernel: [3.229909] usb 4-1: device descriptor read/64, error -32 Jan 17 22:08:15 pd kernel: [3.432786] usb 4-1: new high-speed USB device number 3 using ehci-pci Jan 17 22:08:15 pd kernel: [3.534684] usb 4-1: device descriptor read/64, error -32 Jan 17 22:08:15 pd kernel: [3.737642] usb 4-1: device descriptor read/64, error -32 Yes, this is exactly what I faced. I'd go and venture a guess here since I don't have an idea that DMA somehow gets busted with the GART and thus the errors. Now, those boards normally have an IOMMU too so if you go and enable CONFIG_AMD_IOMMU=y the problem is gone (we're using the real IOMMU for DMA mapping, etc, etc). So dAgeCKo, that would be another thing you could do: try enabling the IOMMU in the BIOS and the above CONFIG option and the issue would be fixed too. Here is below, exactly what the guy from MSI said me after I said him a BIOS upgrade did resolve my bug: "The reacts differently to Win/Linux, but it relies on updates by AMD. The new AGESA in the BIOS might had fixes for Linux." After few researches, it seems that this "BIOS-level" software has effectively a special implementation wrapper for Linux (something I can't understand why actually). For more reference you can find little information here (http://www.coreboot.org/data/LinuxBIOS%20AMD%202006%20Final_10-02-2006.pdf). I can't try the solution you are giving since I can't (and don't want to try to) downgrade my BIOS. Another important thing you might be interested in is that not only my USB 2 weren't working. My mainboard ethernet wasn't working to (and was resolved with the BIOS upgrade too). The ethernet chip is: 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) I don't know if that can be related to what you are saying. At least this fixes it on my box. To the question "how do we fix the GART issue?" I have no answer and would expect more informed opinions from someone else. Actually I can't tell if I have any GART issues. The only thing I can say is that 3D looks to work nicely. However I think I never consumed more memory than my graphic card has. Thanks and HTH. Thanks you too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 18 (acpi)
On Sat, Jan 19, 2013 at 3:22 PM, Sedat Dilek wrote: > On Sat, Jan 19, 2013 at 3:01 PM, Rafael J. Wysocki wrote: >> On Saturday, January 19, 2013 02:50:17 PM Sedat Dilek wrote: >>> On Sat, Jan 19, 2013 at 2:45 PM, Rafael J. Wysocki wrote: >>> > On Friday, January 18, 2013 05:42:20 PM Randy Dunlap wrote: >>> >> On 01/17/13 20:37, Stephen Rothwell wrote: >>> >> > Hi all, >>> >> > >>> >> > Changes since 20130117: >>> >> > >>> >> >>> >> >>> >> on x86_64: >>> >> >>> >> CC drivers/acpi/device_pm.o >>> >> drivers/acpi/device_pm.c:778:5: error: redefinition of >>> >> 'acpi_dev_suspend_late' >>> >> In file included from include/acpi/acpi_drivers.h:29:0, >>> >> from drivers/acpi/device_pm.c:33: >>> >> include/linux/acpi.h:526:19: note: previous definition of >>> >> 'acpi_dev_suspend_late' was here >>> >> drivers/acpi/device_pm.c:810:5: error: redefinition of >>> >> 'acpi_dev_resume_early' >>> >> In file included from include/acpi/acpi_drivers.h:29:0, >>> >> from drivers/acpi/device_pm.c:33: >>> >> include/linux/acpi.h:527:19: note: previous definition of >>> >> 'acpi_dev_resume_early' was here >>> >> drivers/acpi/device_pm.c:828:5: error: redefinition of >>> >> 'acpi_subsys_prepare' >>> >> In file included from include/acpi/acpi_drivers.h:29:0, >>> >> from drivers/acpi/device_pm.c:33: >>> >> include/linux/acpi.h:528:19: note: previous definition of >>> >> 'acpi_subsys_prepare' was here >>> >> drivers/acpi/device_pm.c:846:5: error: redefinition of >>> >> 'acpi_subsys_suspend_late' >>> >> In file included from include/acpi/acpi_drivers.h:29:0, >>> >> from drivers/acpi/device_pm.c:33: >>> >> include/linux/acpi.h:529:19: note: previous definition of >>> >> 'acpi_subsys_suspend_late' was here >>> >> drivers/acpi/device_pm.c:861:5: error: redefinition of >>> >> 'acpi_subsys_resume_early' >>> >> In file included from include/acpi/acpi_drivers.h:29:0, >>> >> from drivers/acpi/device_pm.c:33: >>> >> include/linux/acpi.h:530:19: note: previous definition of >>> >> 'acpi_subsys_resume_early' was here >>> >> make[3]: *** [drivers/acpi/device_pm.o] Error 1 >>> >> >>> >> >>> >> >>> >> >>> >> Full randconfig file is attached. >>> > >>> > Thanks, I'll take it for inclusion into the build testing framework. >>> > >>> > The appended patch fixes the problem for me. >>> > >>> > Thanks, >>> > Rafael >>> > >>> > >>> > --- >>> > From: Rafael J. Wysocki >>> > Subject: ACPI / PM: Fix build for unusual combination of Kconfig options >>> > >>> > CONFIG_PM_SLEEP may be set even if CONFIG_ACPI_SLEEP is unset, >>> > although that is unusual. For this reason, make the headers of >>> > functions built for both CONFIG_ACPI and CONFIG_PM_SLEEP set >>> > simultaneously depend on that combination of Kconfig options >>> > instead of CONFIG_ACPI_SLEEP. >>> > >>> > This fixes a build problem reported by Randy Dunlap. >>> > >>> > Signed-off-by: Rafael J. Wysocki >>> > --- >>> > include/linux/acpi.h |2 +- >>> > 1 file changed, 1 insertion(+), 1 deletion(-) >>> > >>> > Index: linux-pm/include/linux/acpi.h >>> > === >>> > --- linux-pm.orig/include/linux/acpi.h >>> > +++ linux-pm/include/linux/acpi.h >>> >>> Can you tell me how do you create such a patch with "Index:" line? >>> >>> linux-pm.orig as a reference is not very meaninful :-). >>> >>> If this is against Linux-Next (next-20130118) I would like to see: >>> --- next-20130118.orig/path/to/file >>> +++ next-20130118/path/to/file >>> >>> I had used 'git format-patch' with '--subject-prefix="PATCH >>> next-20130118"' option in such a case. >>> Just as a hint by not telling you how you should do your job. >>> >>> /me is still a Git n00b! >> >> Well, I use quilt to generate patches. :-) >> >> This particular one was generated with "quilt refresh --diffstat", I'm not >> sure how to get the same result using git, sorry. >> > > OK, I know I am a bad Git teacher, but from my p00r Git experiences... > > I required some of the below options of 'git format-patch' for the > Freetz router project. > > [ Fight with "p0" VS. "p1" patch-format aka w/ or w/o prefix ] > > In general Freetz wants its patches in "p0" patch-format to fit its > own "freetz_patch" tool. > ( When I asked on the Git ML people did not know/like the terms "p0" > and "p1" so it's in parenthesis. ) > This means patches should NOT contain "a/" and "b/" prefixes. > >--no-prefix >Do not show any source or destination prefix. > > [ Add a "source" (override "a/") and a "destination" (override "b/") prefix ] > > You will like this one :-). > In combination with the above I had to add > "--src-prefix=linux-2.6.13.1.orig" and -dst-prefix="linux-2.6.13.1" > for kernel-patches. > YES, my router has a very ancient kernel-release :-(! > >--src-prefix= >Show the given source prefix instead of "a/". > >--dst-prefix= >Show the
Re: linux-next: Tree for Jan 18 (acpi)
On Sat, Jan 19, 2013 at 3:01 PM, Rafael J. Wysocki wrote: > On Saturday, January 19, 2013 02:50:17 PM Sedat Dilek wrote: >> On Sat, Jan 19, 2013 at 2:45 PM, Rafael J. Wysocki wrote: >> > On Friday, January 18, 2013 05:42:20 PM Randy Dunlap wrote: >> >> On 01/17/13 20:37, Stephen Rothwell wrote: >> >> > Hi all, >> >> > >> >> > Changes since 20130117: >> >> > >> >> >> >> >> >> on x86_64: >> >> >> >> CC drivers/acpi/device_pm.o >> >> drivers/acpi/device_pm.c:778:5: error: redefinition of >> >> 'acpi_dev_suspend_late' >> >> In file included from include/acpi/acpi_drivers.h:29:0, >> >> from drivers/acpi/device_pm.c:33: >> >> include/linux/acpi.h:526:19: note: previous definition of >> >> 'acpi_dev_suspend_late' was here >> >> drivers/acpi/device_pm.c:810:5: error: redefinition of >> >> 'acpi_dev_resume_early' >> >> In file included from include/acpi/acpi_drivers.h:29:0, >> >> from drivers/acpi/device_pm.c:33: >> >> include/linux/acpi.h:527:19: note: previous definition of >> >> 'acpi_dev_resume_early' was here >> >> drivers/acpi/device_pm.c:828:5: error: redefinition of >> >> 'acpi_subsys_prepare' >> >> In file included from include/acpi/acpi_drivers.h:29:0, >> >> from drivers/acpi/device_pm.c:33: >> >> include/linux/acpi.h:528:19: note: previous definition of >> >> 'acpi_subsys_prepare' was here >> >> drivers/acpi/device_pm.c:846:5: error: redefinition of >> >> 'acpi_subsys_suspend_late' >> >> In file included from include/acpi/acpi_drivers.h:29:0, >> >> from drivers/acpi/device_pm.c:33: >> >> include/linux/acpi.h:529:19: note: previous definition of >> >> 'acpi_subsys_suspend_late' was here >> >> drivers/acpi/device_pm.c:861:5: error: redefinition of >> >> 'acpi_subsys_resume_early' >> >> In file included from include/acpi/acpi_drivers.h:29:0, >> >> from drivers/acpi/device_pm.c:33: >> >> include/linux/acpi.h:530:19: note: previous definition of >> >> 'acpi_subsys_resume_early' was here >> >> make[3]: *** [drivers/acpi/device_pm.o] Error 1 >> >> >> >> >> >> >> >> >> >> Full randconfig file is attached. >> > >> > Thanks, I'll take it for inclusion into the build testing framework. >> > >> > The appended patch fixes the problem for me. >> > >> > Thanks, >> > Rafael >> > >> > >> > --- >> > From: Rafael J. Wysocki >> > Subject: ACPI / PM: Fix build for unusual combination of Kconfig options >> > >> > CONFIG_PM_SLEEP may be set even if CONFIG_ACPI_SLEEP is unset, >> > although that is unusual. For this reason, make the headers of >> > functions built for both CONFIG_ACPI and CONFIG_PM_SLEEP set >> > simultaneously depend on that combination of Kconfig options >> > instead of CONFIG_ACPI_SLEEP. >> > >> > This fixes a build problem reported by Randy Dunlap. >> > >> > Signed-off-by: Rafael J. Wysocki >> > --- >> > include/linux/acpi.h |2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > Index: linux-pm/include/linux/acpi.h >> > === >> > --- linux-pm.orig/include/linux/acpi.h >> > +++ linux-pm/include/linux/acpi.h >> >> Can you tell me how do you create such a patch with "Index:" line? >> >> linux-pm.orig as a reference is not very meaninful :-). >> >> If this is against Linux-Next (next-20130118) I would like to see: >> --- next-20130118.orig/path/to/file >> +++ next-20130118/path/to/file >> >> I had used 'git format-patch' with '--subject-prefix="PATCH >> next-20130118"' option in such a case. >> Just as a hint by not telling you how you should do your job. >> >> /me is still a Git n00b! > > Well, I use quilt to generate patches. :-) > > This particular one was generated with "quilt refresh --diffstat", I'm not > sure how to get the same result using git, sorry. > OK, I know I am a bad Git teacher, but from my p00r Git experiences... I required some of the below options of 'git format-patch' for the Freetz router project. [ Fight with "p0" VS. "p1" patch-format aka w/ or w/o prefix ] In general Freetz wants its patches in "p0" patch-format to fit its own "freetz_patch" tool. ( When I asked on the Git ML people did not know/like the terms "p0" and "p1" so it's in parenthesis. ) This means patches should NOT contain "a/" and "b/" prefixes. --no-prefix Do not show any source or destination prefix. [ Add a "source" (override "a/") and a "destination" (override "b/") prefix ] You will like this one :-). In combination with the above I had to add "--src-prefix=linux-2.6.13.1.orig" and -dst-prefix="linux-2.6.13.1" for kernel-patches. YES, my router has a very ancient kernel-release :-(! --src-prefix= Show the given source prefix instead of "a/". --dst-prefix= Show the given destination prefix instead of "b/". [ Do NOT number patches in a series ] And last but not least, I personally do not like to see "[PATCH] 12/23" in a series of patches. Suppress this by using
[PATCH] tty: Correct tty buffer flush.
The root of problem is carelessly zeroing pointer(in function
__tty_buffer_flush()),
when another thread can use it. It can be cause of "NULL pointer dereference".
Main idea of the patch, this is never free last (struct tty_buffer) in the
active buffer.
Only flush the data for ldisc(buf->head->read = buf->head->commit).
At that moment driver can collect(write) data in buffer without conflict.
It is repeat behavior of flush_to_ldisc(), only without feeding data to ldisc.
Also revert:
commit c56a00a165712fd73081f40044b1e64407bb1875
tty: hold lock across tty buffer finding and buffer filling
In order to delete the unneeded locks any more.
Signed-off-by: Ilya Zykov
---
drivers/tty/tty_buffer.c | 92 +++---
1 files changed, 22 insertions(+), 70 deletions(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index d6969f6..61ec4dd 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -119,11 +119,14 @@ static void __tty_buffer_flush(struct tty_port *port)
struct tty_bufhead *buf = >buf;
struct tty_buffer *thead;
- while ((thead = buf->head) != NULL) {
- buf->head = thead->next;
- tty_buffer_free(port, thead);
+ if (unlikely(buf->head == NULL))
+ return;
+ while ((thead = buf->head->next) != NULL) {
+ tty_buffer_free(port, buf->head);
+ buf->head = thead;
}
- buf->tail = NULL;
+ WARN_ON(buf->head != buf->tail);
+ buf->head->read = buf->head->commit;
}
/**
@@ -194,19 +197,22 @@ static struct tty_buffer *tty_buffer_find(struct tty_port
*port, size_t size)
have queued and recycle that ? */
}
/**
- * __tty_buffer_request_room - grow tty buffer if
needed
+ * tty_buffer_request_room - grow tty buffer if needed
* @tty: tty structure
* @size: size desired
*
* Make at least size bytes of linear space available for the tty
* buffer. If we fail return the size we managed to find.
- * Locking: Caller must hold port->buf.lock
+ *
+ * Locking: Takes port->buf.lock
*/
-static int __tty_buffer_request_room(struct tty_port *port, size_t size)
+int tty_buffer_request_room(struct tty_port *port, size_t size)
{
struct tty_bufhead *buf = >buf;
struct tty_buffer *b, *n;
int left;
+ unsigned long flags;
+ spin_lock_irqsave(>lock, flags);
/* OPTIMISATION: We could keep a per tty "zero" sized buffer to
remove this conditional if its worth it. This would be invisible
to the callers */
@@ -228,31 +234,9 @@ static int __tty_buffer_request_room(struct tty_port
*port, size_t size)
} else
size = left;
}
-
+ spin_unlock_irqrestore(>lock, flags);
return size;
}
-
-
-/**
- * tty_buffer_request_room - grow tty buffer if needed
- * @port: tty port structure
- * @size: size desired
- *
- * Make at least size bytes of linear space available for the tty
- * buffer. If we fail return the size we managed to find.
- *
- * Locking: Takes port->buf.lock
- */
-int tty_buffer_request_room(struct tty_port *port, size_t size)
-{
- unsigned long flags;
- int length;
-
- spin_lock_irqsave(>buf.lock, flags);
- length = __tty_buffer_request_room(port, size);
- spin_unlock_irqrestore(>buf.lock, flags);
- return length;
-}
EXPORT_SYMBOL_GPL(tty_buffer_request_room);
/**
@@ -271,26 +255,18 @@ EXPORT_SYMBOL_GPL(tty_buffer_request_room);
int tty_insert_flip_string_fixed_flag(struct tty_port *port,
const unsigned char *chars, char flag, size_t size)
{
- struct tty_bufhead *buf = >buf;
int copied = 0;
do {
int goal = min_t(size_t, size - copied, TTY_BUFFER_PAGE);
- int space;
- unsigned long flags;
- struct tty_buffer *tb;
-
- spin_lock_irqsave(>lock, flags);
- space = __tty_buffer_request_room(port, goal);
- tb = buf->tail;
+ int space = tty_buffer_request_room(port, goal);
+ struct tty_buffer *tb = port->buf.tail;
/* If there is no space then tb may be NULL */
if (unlikely(space == 0)) {
- spin_unlock_irqrestore(>lock, flags);
break;
}
memcpy(tb->char_buf_ptr + tb->used, chars, space);
memset(tb->flag_buf_ptr + tb->used, flag, space);
tb->used += space;
- spin_unlock_irqrestore(>lock, flags);
copied += space;
chars += space;
/* There is a small chance that we need to split the data over
@@ -317,26 +293,18 @@ EXPORT_SYMBOL(tty_insert_flip_string_fixed_flag);
int
Re: [PATCH v2 19/76] ARC: Signal handling
On Saturday 19 January 2013 08:53 AM, Al Viro wrote:
> On Fri, Jan 18, 2013 at 05:54:33PM +0530, Vineet Gupta wrote:
>> +SYSCALL_DEFINE0(rt_sigreturn)
>> +{
>> +struct rt_sigframe __user *sf;
>> +unsigned int magic;
>> +int err;
>> +struct pt_regs *regs = task_pt_regs(current);
> ITYM current_pt_regs()...
Done.
>
>> +if (unlikely(is_do_ss_needed(magic)))
>> +if (do_sigaltstack(>uc.uc_stack, NULL, regs->sp) == -EFAULT)
> if (!restore_altstack(>uc.uc_stack))
> please...
>
>> +stk.ss_sp = (void __user *)current->sas_ss_sp;
>> +stk.ss_flags = sas_ss_flags(regs->sp);
>> +stk.ss_size = current->sas_ss_size;
>> +err |= __copy_to_user(>uc.uc_stack, , sizeof(stk));
> that would be
> err |= __save_altstack(>uc.uc_stack, regs->sp);
>
Actually altstack consolidation tracking changes are already present in patch
41/76 - which has other 3.8 specific bits too. This is more of a reflection of
my
3.7 baseline and a subsequent migration to 3.8. But you are right, it is
creating
undue confusion - I'll chop-n-dice-n-squash those bits into appropriate patches.
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] power: bq27x00_battery: Export all battery registers via sysfs
bq27xxx batteries have a lot of properties, more than power_supply interface.
Some of them can be usefull for userspace applications (like CI bit) but
does not make sense to add bq specified property to power_supply interface.
When bq27x00_battery is not loaded userspace application (like i2cget) can
use /dev/i2c-* interface for raw access. But when kernel module is attached
to i2c device, userspace applications cannot access it via /dev/i2c-*.
Also it is not usefull for userspace to unload module before reading values
form /dev/i2c-* and then load it again.
This patch exporting all battery registers to sysfs entry "registers" in
battery power_supply directory. Format is "register=value" on separate line.
Because length of registers are different for each bq battery more for loops
are needed.
Signed-off-by: Pali Rohár
---
drivers/power/bq27x00_battery.c | 98 +--
1 file changed, 95 insertions(+), 3 deletions(-)
diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c
index 7087d0d..af0f68f 100644
--- a/drivers/power/bq27x00_battery.c
+++ b/drivers/power/bq27x00_battery.c
@@ -690,6 +690,90 @@ static void bq27x00_external_power_changed(struct
power_supply *psy)
schedule_delayed_work(>work, 0);
}
+/* code for register device access via sysfs */
+
+static ssize_t bq27x00_battery_sysfs_print_reg(struct bq27x00_device_info *di,
+ u8 reg, bool single, char *buf)
+{
+ int ret = bq27x00_read(di, reg, single);
+ if (ret < 0)
+ return sprintf(buf, "%#.2x=error %d\n", reg, ret);
+ else
+ return sprintf(buf, "%#.2x=%#.2x\n", reg, ret);
+}
+
+static ssize_t bq27x00_battery_sysfs_show_registers(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct power_supply *psy = dev_get_drvdata(dev);
+ struct bq27x00_device_info *di = container_of(psy,
+ struct bq27x00_device_info,
+ bat);
+ u8 reg;
+ ssize_t ret = 0;
+
+ switch (di->chip) {
+
+ case BQ27000:
+ for (reg=0x00; reg<=0x01; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ for (reg=0x02; reg<=0x08; reg+=2)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
buf+ret);
+ for (reg=0x0A; reg<=0x0B; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ for (reg=0x0C; reg<=0x2A; reg+=2)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
buf+ret);
+ for (reg=0x2C; reg<=0x7F; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ break;
+
+ case BQ27500:
+ for (reg=0x00; reg<=0x2C; reg+=2)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
buf+ret);
+ for (reg=0x2E; reg<=0x3B; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ for (reg=0x3C; reg<=0x3C; reg+=2)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
buf+ret);
+ for (reg=0x3E; reg<=0x7F; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ break;
+
+ case BQ27425:
+ for (reg=0x00; reg<=0x3C; reg+=2)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, false,
buf+ret);
+ for (reg=0x3E; reg<=0x7F; reg+=1)
+ ret += bq27x00_battery_sysfs_print_reg(di, reg, true,
buf+ret);
+ break;
+
+ }
+
+ return ret;
+}
+
+static DEVICE_ATTR(registers, S_IRUGO,
+ bq27x00_battery_sysfs_show_registers, NULL);
+
+static struct attribute *bq27x00_battery_sysfs_attributes[] = {
+ _attr_registers.attr,
+ NULL,
+};
+
+static const struct attribute_group bq27x00_battery_sysfs_attr_group = {
+ .attrs = bq27x00_battery_sysfs_attributes,
+};
+
+static int bq27x00_battery_sysfs_init(struct bq27x00_device_info *di)
+{
+ return sysfs_create_group(>bat.dev->kobj,
+ _battery_sysfs_attr_group);
+}
+
+static void bq27x00_battery_sysfs_exit(struct bq27x00_device_info *di)
+{
+ sysfs_remove_group(>bat.dev->kobj,
+ _battery_sysfs_attr_group);
+}
+
static int bq27x00_powersupply_init(struct bq27x00_device_info *di)
{
int ret;
@@ -705,15 +789,22 @@ static int bq27x00_powersupply_init(struct
bq27x00_device_info *di)
di->bat.get_property = bq27x00_battery_get_property;
di->bat.external_power_changed = bq27x00_external_power_changed;
- INIT_DELAYED_WORK(>work, bq27x00_battery_poll);
- mutex_init(>lock);
-
ret
Re: linux-next: Tree for Jan 18 (acpi)
On Saturday, January 19, 2013 02:50:17 PM Sedat Dilek wrote: > On Sat, Jan 19, 2013 at 2:45 PM, Rafael J. Wysocki wrote: > > On Friday, January 18, 2013 05:42:20 PM Randy Dunlap wrote: > >> On 01/17/13 20:37, Stephen Rothwell wrote: > >> > Hi all, > >> > > >> > Changes since 20130117: > >> > > >> > >> > >> on x86_64: > >> > >> CC drivers/acpi/device_pm.o > >> drivers/acpi/device_pm.c:778:5: error: redefinition of > >> 'acpi_dev_suspend_late' > >> In file included from include/acpi/acpi_drivers.h:29:0, > >> from drivers/acpi/device_pm.c:33: > >> include/linux/acpi.h:526:19: note: previous definition of > >> 'acpi_dev_suspend_late' was here > >> drivers/acpi/device_pm.c:810:5: error: redefinition of > >> 'acpi_dev_resume_early' > >> In file included from include/acpi/acpi_drivers.h:29:0, > >> from drivers/acpi/device_pm.c:33: > >> include/linux/acpi.h:527:19: note: previous definition of > >> 'acpi_dev_resume_early' was here > >> drivers/acpi/device_pm.c:828:5: error: redefinition of > >> 'acpi_subsys_prepare' > >> In file included from include/acpi/acpi_drivers.h:29:0, > >> from drivers/acpi/device_pm.c:33: > >> include/linux/acpi.h:528:19: note: previous definition of > >> 'acpi_subsys_prepare' was here > >> drivers/acpi/device_pm.c:846:5: error: redefinition of > >> 'acpi_subsys_suspend_late' > >> In file included from include/acpi/acpi_drivers.h:29:0, > >> from drivers/acpi/device_pm.c:33: > >> include/linux/acpi.h:529:19: note: previous definition of > >> 'acpi_subsys_suspend_late' was here > >> drivers/acpi/device_pm.c:861:5: error: redefinition of > >> 'acpi_subsys_resume_early' > >> In file included from include/acpi/acpi_drivers.h:29:0, > >> from drivers/acpi/device_pm.c:33: > >> include/linux/acpi.h:530:19: note: previous definition of > >> 'acpi_subsys_resume_early' was here > >> make[3]: *** [drivers/acpi/device_pm.o] Error 1 > >> > >> > >> > >> > >> Full randconfig file is attached. > > > > Thanks, I'll take it for inclusion into the build testing framework. > > > > The appended patch fixes the problem for me. > > > > Thanks, > > Rafael > > > > > > --- > > From: Rafael J. Wysocki > > Subject: ACPI / PM: Fix build for unusual combination of Kconfig options > > > > CONFIG_PM_SLEEP may be set even if CONFIG_ACPI_SLEEP is unset, > > although that is unusual. For this reason, make the headers of > > functions built for both CONFIG_ACPI and CONFIG_PM_SLEEP set > > simultaneously depend on that combination of Kconfig options > > instead of CONFIG_ACPI_SLEEP. > > > > This fixes a build problem reported by Randy Dunlap. > > > > Signed-off-by: Rafael J. Wysocki > > --- > > include/linux/acpi.h |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Index: linux-pm/include/linux/acpi.h > > === > > --- linux-pm.orig/include/linux/acpi.h > > +++ linux-pm/include/linux/acpi.h > > Can you tell me how do you create such a patch with "Index:" line? > > linux-pm.orig as a reference is not very meaninful :-). > > If this is against Linux-Next (next-20130118) I would like to see: > --- next-20130118.orig/path/to/file > +++ next-20130118/path/to/file > > I had used 'git format-patch' with '--subject-prefix="PATCH > next-20130118"' option in such a case. > Just as a hint by not telling you how you should do your job. > > /me is still a Git n00b! Well, I use quilt to generate patches. :-) This particular one was generated with "quilt refresh --diffstat", I'm not sure how to get the same result using git, sorry. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 13/76] ARC: Low level IRQ/Trap/Exception Handling
On Saturday 19 January 2013 09:01 AM, Al Viro wrote: > On Fri, Jan 18, 2013 at 05:54:27PM +0530, Vineet Gupta wrote: > >> +; --- (Slow Path #3) notify_resume --- >> +.Lchk_notify_resume: >> +btst r9, TIF_NOTIFY_RESUME >> +blnz @do_notify_resume >> +b resume_user_mode_begin ; unconditionally back to U mode ret >> chks >> +; for single exit point from this block > Umm... Can we even get there without NOTIFY_RESUME? Again, there's > future-proofing and there's laying minefields - think what will happen > if we *do* get there with some bit in _TIF_WORK_MASK that isn't recognized > by any of these cases. Looping forever? IMHO, for future safe-ing, the test for TIF_NOTIFY_RESUME is correct (as we will need to add that check the moment a new bit is introduced in _TIF_WORK_MASK). Regarding the infinite loop, I would assume that _TIF_WORK_MASK is golden (fixed by your prior comment) so anyone touching it needs to add corresponding code here - IMHO we don't need to handle that scenario (maybe add a comment in thread_info.h). With that assumption, the unconditional branch would go back to start and the re-test for TIF_WORK_MASK will break the loop even if any stray bit was set. So essentially we don't need any code change ! Am I overlooking something here ? -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 18 (acpi)
On Sat, Jan 19, 2013 at 2:45 PM, Rafael J. Wysocki wrote: > On Friday, January 18, 2013 05:42:20 PM Randy Dunlap wrote: >> On 01/17/13 20:37, Stephen Rothwell wrote: >> > Hi all, >> > >> > Changes since 20130117: >> > >> >> >> on x86_64: >> >> CC drivers/acpi/device_pm.o >> drivers/acpi/device_pm.c:778:5: error: redefinition of >> 'acpi_dev_suspend_late' >> In file included from include/acpi/acpi_drivers.h:29:0, >> from drivers/acpi/device_pm.c:33: >> include/linux/acpi.h:526:19: note: previous definition of >> 'acpi_dev_suspend_late' was here >> drivers/acpi/device_pm.c:810:5: error: redefinition of >> 'acpi_dev_resume_early' >> In file included from include/acpi/acpi_drivers.h:29:0, >> from drivers/acpi/device_pm.c:33: >> include/linux/acpi.h:527:19: note: previous definition of >> 'acpi_dev_resume_early' was here >> drivers/acpi/device_pm.c:828:5: error: redefinition of 'acpi_subsys_prepare' >> In file included from include/acpi/acpi_drivers.h:29:0, >> from drivers/acpi/device_pm.c:33: >> include/linux/acpi.h:528:19: note: previous definition of >> 'acpi_subsys_prepare' was here >> drivers/acpi/device_pm.c:846:5: error: redefinition of >> 'acpi_subsys_suspend_late' >> In file included from include/acpi/acpi_drivers.h:29:0, >> from drivers/acpi/device_pm.c:33: >> include/linux/acpi.h:529:19: note: previous definition of >> 'acpi_subsys_suspend_late' was here >> drivers/acpi/device_pm.c:861:5: error: redefinition of >> 'acpi_subsys_resume_early' >> In file included from include/acpi/acpi_drivers.h:29:0, >> from drivers/acpi/device_pm.c:33: >> include/linux/acpi.h:530:19: note: previous definition of >> 'acpi_subsys_resume_early' was here >> make[3]: *** [drivers/acpi/device_pm.o] Error 1 >> >> >> >> >> Full randconfig file is attached. > > Thanks, I'll take it for inclusion into the build testing framework. > > The appended patch fixes the problem for me. > > Thanks, > Rafael > > > --- > From: Rafael J. Wysocki > Subject: ACPI / PM: Fix build for unusual combination of Kconfig options > > CONFIG_PM_SLEEP may be set even if CONFIG_ACPI_SLEEP is unset, > although that is unusual. For this reason, make the headers of > functions built for both CONFIG_ACPI and CONFIG_PM_SLEEP set > simultaneously depend on that combination of Kconfig options > instead of CONFIG_ACPI_SLEEP. > > This fixes a build problem reported by Randy Dunlap. > > Signed-off-by: Rafael J. Wysocki > --- > include/linux/acpi.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-pm/include/linux/acpi.h > === > --- linux-pm.orig/include/linux/acpi.h > +++ linux-pm/include/linux/acpi.h Can you tell me how do you create such a patch with "Index:" line? linux-pm.orig as a reference is not very meaninful :-). If this is against Linux-Next (next-20130118) I would like to see: --- next-20130118.orig/path/to/file +++ next-20130118/path/to/file I had used 'git format-patch' with '--subject-prefix="PATCH next-20130118"' option in such a case. Just as a hint by not telling you how you should do your job. /me is still a Git n00b! - Sedat - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 18 (acpi)
On Friday, January 18, 2013 05:42:20 PM Randy Dunlap wrote:
> On 01/17/13 20:37, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20130117:
> >
>
>
> on x86_64:
>
> CC drivers/acpi/device_pm.o
> drivers/acpi/device_pm.c:778:5: error: redefinition of 'acpi_dev_suspend_late'
> In file included from include/acpi/acpi_drivers.h:29:0,
> from drivers/acpi/device_pm.c:33:
> include/linux/acpi.h:526:19: note: previous definition of
> 'acpi_dev_suspend_late' was here
> drivers/acpi/device_pm.c:810:5: error: redefinition of 'acpi_dev_resume_early'
> In file included from include/acpi/acpi_drivers.h:29:0,
> from drivers/acpi/device_pm.c:33:
> include/linux/acpi.h:527:19: note: previous definition of
> 'acpi_dev_resume_early' was here
> drivers/acpi/device_pm.c:828:5: error: redefinition of 'acpi_subsys_prepare'
> In file included from include/acpi/acpi_drivers.h:29:0,
> from drivers/acpi/device_pm.c:33:
> include/linux/acpi.h:528:19: note: previous definition of
> 'acpi_subsys_prepare' was here
> drivers/acpi/device_pm.c:846:5: error: redefinition of
> 'acpi_subsys_suspend_late'
> In file included from include/acpi/acpi_drivers.h:29:0,
> from drivers/acpi/device_pm.c:33:
> include/linux/acpi.h:529:19: note: previous definition of
> 'acpi_subsys_suspend_late' was here
> drivers/acpi/device_pm.c:861:5: error: redefinition of
> 'acpi_subsys_resume_early'
> In file included from include/acpi/acpi_drivers.h:29:0,
> from drivers/acpi/device_pm.c:33:
> include/linux/acpi.h:530:19: note: previous definition of
> 'acpi_subsys_resume_early' was here
> make[3]: *** [drivers/acpi/device_pm.o] Error 1
>
>
>
>
> Full randconfig file is attached.
Thanks, I'll take it for inclusion into the build testing framework.
The appended patch fixes the problem for me.
Thanks,
Rafael
---
From: Rafael J. Wysocki
Subject: ACPI / PM: Fix build for unusual combination of Kconfig options
CONFIG_PM_SLEEP may be set even if CONFIG_ACPI_SLEEP is unset,
although that is unusual. For this reason, make the headers of
functions built for both CONFIG_ACPI and CONFIG_PM_SLEEP set
simultaneously depend on that combination of Kconfig options
instead of CONFIG_ACPI_SLEEP.
This fixes a build problem reported by Randy Dunlap.
Signed-off-by: Rafael J. Wysocki
---
include/linux/acpi.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-pm/include/linux/acpi.h
===
--- linux-pm.orig/include/linux/acpi.h
+++ linux-pm/include/linux/acpi.h
@@ -511,7 +511,7 @@ static inline int acpi_subsys_runtime_su
static inline int acpi_subsys_runtime_resume(struct device *dev) { return 0; }
#endif
-#ifdef CONFIG_ACPI_SLEEP
+#if defined(CONFIG_ACPI) && defined(CONFIG_PM_SLEEP)
int acpi_dev_suspend_late(struct device *dev);
int acpi_dev_resume_early(struct device *dev);
int acpi_subsys_prepare(struct device *dev);
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 18 [ BROKEN tty-next on suspend ]
On Fri, Jan 18, 2013 at 5:37 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130117: > > Undropped tree: samung > > The powerpc tree still had a build failure. > > The driver-core tree gained a build failure for which I applied a merge > fix patch. > > The gpio-lw tree gained a build failure so I used the version from > next-20130117. > > The samsung tree lost the majority of its conflicts but gained more > against the arm-soc and slave-dma tree. > > > [ TO TTY folks ] + [ CC Rafael and linux-pm ML ] In the end it turned out to be a problem with tty-next (see thread in [1]). I am hitting the problem reproducibly on PM/suspend. Rafael gave me some cool help on pm-testing, thanks (see also thread in [1]) Ilya has sent a patch to [3] which needs to be refreshed. AFAICS also be adapted to the recent changes to tty_port and tty_buf. But hey, I am no TTY expert so it is up to you. Hope you will CC me on the patch. Thanks! - Sedat - [1] http://marc.info/?t=13585471403=1=2 [2] http://git.kernel.org/?p=linux/kernel/git/gregkh/tty.git;a=shortlog;h=refs/heads/tty-next [3] http://marc.info/?t=13545286833=1=2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i915-related and general system freezes with specific kernel config // IOMMU
Hi Mihai, You have a gen4.5 chipset which is known to be utterly broken for IOMMU+intel gpu. Looks like a few distros started enabling IOMMU by default (fc18 has similar issues) and we've never added the proper quirks. See https://bugzilla.kernel.org/show_bug.cgi?id=51921 for a proposed patch to fix this (i.e. automatically set intel_iommu=igfx_off for affected platfroms). Testing highly welcome. Cheers, Daniel On Sat, Jan 19, 2013 at 12:48 AM, Mihai Moldovan wrote: > Hi Daniel, David and everyone else, > > I'm experiencing system freezes on a box using the vanilla 3.7.2 (actually > down > to 3.2 or something) kernel with a custom configuration. > > There are two problems: > > [*] related to i915 with modeset enabled; upon loading the kernel module > with > modeset=1, the box will instantly freeze. > [*] seemingly unrelated to i915; the box will randomly freeze without any > clear indication of why and moreover no apparent trigger. > > After months, nay, years of being "locked" into 3.0.2 for the random freezes > and > i915 problems, I started playing with the kernel again and out of sheer > desperation installed the current debian testing kernel, based on 3.2.35. > > From what I could see, it worked fine... no more crashes, neither when loading > i915, nor randomly after some time (well, at least not for a day.) > > This time out of frustration, I ripped the config file used by debian to build > the kernel out of its deb package and rebuilt my (almost[1]) vanilla 3.7.2 > kernel with this configuration exactly, updated via the oldconfig target and > changed to include AHCI, RAID and SCSI drivers statically, so that I wouldn't > need some initramfs to boot my system ... and ... with this config, I am not > experiencing any i915 problems nor system freezes?! > > I then tried to spot any "obvious" differences between the two config files > and > to "approximate" my config file to the debian config. > > Comparing the dmesg output from 3.7.2 built with the slightly modified debian > config to my 3.7.2 built with my config, I came across IOMMU entries which > differed. My kernel config enables Intel IOMMU by default, while the debian > config doesn't. > > Looking up IOMMU stuff in Documentation/, I found out that IOMMU *may* have > bugs > with the internal graphics card and there is an option called > intel_iommu=igfx_off to disable IOMMU remapping for the integrated graphics > card... > > I tried booting "my" kernel with intel_iommu=igfx_off and lo and behold, no > more > crashes when loading i915 with modeset enabled! Yay... but anyway, that's > definitely a kernel bug. > > Next, regarding the random freezes... so did the kernel booted with > intel_iommu=igfx_off. It seems the random freeze issue is kind of decoupled of > the graphics issue. > > Testing further, I rebooted using iommu=off and intel_iommu=off. So far, I had > no random crashes, but the system uptime of REPLACEME minutes is too > small to draw conclusions yet. > > Anyway, booting with both options made my USB ports unusable. Also, my PCIe > and > PCI WiFi cards stopped working. Seems like the kernel can't enumerate those > devices due to... guess what, DMA remapping errors! > > Note that the debian-config kernel with CONFIG_INTEL_IOMMU=y and > CONFIG_INTEL_IOMMU_DEFAULT_ON=n did not produce such errors. Both my USB and > WiFi cards have been working. > > Any idea why is that? > > As I'm not sure who to CC exactly, I'm adding both the i915 and Intel IOMMU > maintainers Daniel and David. > > I have included several files: > > [*] the "debianish" config file > [*] my current config file (IOMMU still on by default) > [*] dmesg for the kernel built with the "debianish" config file > [*] dmesg for the kernel built with "my" config file, no IOMMU options > passed > [*] dmesg for the kernel built with "my" config file, intel_iommu=igfx_off > passed > [*] dmesg for the kernel built with "my" config file, iommu=off and > intel_iommu=off passed > > Hope we can squash those bugs! > > Best regards, > > > > Mihai > > > > > [1] only one "external" patch applied to ath9k, totally unrelated to the rest > of > the system, just changing regulatory stuff. > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 10/76] ARC: Fundamental ARCH data-types/defines
On Saturday 19 January 2013 08:55 AM, Al Viro wrote: > On Fri, Jan 18, 2013 at 05:54:24PM +0530, Vineet Gupta wrote: > >> +/* work to do on interrupt/exception return */ >> +#define _TIF_WORK_MASK (0x & ~_TIF_SYSCALL_TRACE) > Yuck... Use the real set, please - there's future-proofing and then there's > leaving nasty minefields; this is the latter... Rightly so - fixed in next revision. BTW I'm not bothering with SYSCALL_AUDIT yet, so that's out of those. -#define _TIF_WORK_MASK (0x & ~_TIF_SYSCALL_TRACE) +#define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING \ +_TIF_NOTIFY_RESUME) Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] of: dma.c: fix memory leakage
The memory allocated to ofdma might be a leakage when error occurs.
Signed-off-by: Cong Ding
---
drivers/of/dma.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index 59631b2..583e50e3 100644
--- a/drivers/of/dma.c
+++ b/drivers/of/dma.c
@@ -107,6 +107,7 @@ int of_dma_controller_register(struct device_node *np,
if (!nbcells) {
pr_err("%s: #dma-cells property is missing or invalid\n",
__func__);
+ kfree(ofdma);
return -EINVAL;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iwlegacy: don't return zero on failure paths in il4965_pci_probe()
If hardware is not ready, il4965_pci_probe() breaks off initialization,
deallocates all resources, but returns zero.
The patch adds -EIO as return value in this case.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/net/wireless/iwlegacy/4965-mac.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c
b/drivers/net/wireless/iwlegacy/4965-mac.c
index c3fbf67..c805108 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -6553,6 +6553,7 @@ il4965_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
il4965_prepare_card_hw(il);
if (!il->hw_ready) {
IL_WARN("Failed, HW not ready\n");
+ err = -EIO;
goto out_iounmap;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 16/76] ARC: Syscall support (no-legacy-syscall ABI)
On Saturday 19 January 2013 08:39 AM, Al Viro wrote: > Please, collapse your #36--#40 into that one (and I'd probably fold #17 > here as well, to simplify that reordering). Sure, it's not a bisection > hazard, but... Thanks again for the review Al. Sure, I can do that - however because those patches have bits in arch/arc/Kconfig, I'll have to move the Build system patch towards start of series, or simply chop off Kconfig bits out of those and add them later - what do you prefer ? My only reason for chunking those up was to capture the intermediate development of how execve and friends were generalized (and have limited revision history even in initial upstream version). While I was used to the old code, specially copy_thread() between 1st and last change seemed to be almost rewritten. Having said that, I don't have strong opinion either ways. Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IIO ADC support for AD7923
On 01/18/2013 11:02 PM, Getz, Robin wrote: > On Thu 17 Jan 2013 12:36, Lars-Peter Clausen pondered: >> On 01/17/2013 06:11 PM, Alessandro Rubini wrote: >>> [...] >>> >>> But yes, you are right. I'm working on another I/O subsystem. We are >>> gong to release zio-1.0 in a few days, because the thing is mature >>> and used in production. > > Neither means it's a good idea for upstream :) > >> Still it's a very bad idea to have two subsystem which have a huge overlap >> in both functionality and targeted devices. It will gives us all lots of >> headaches later on. As IIO continues to evolve it will get support for some >> of the features that only ZIO supports at the moment and as ZIO grows it >> will get support for features currently only supported by IIO. So in the >> end we have two frameworks for the very same purpose. > > I want to strongly agree with Lars-Peter. Lets work together on one thing - > which tries to solve all the our system level issues. As an end user - I > don't want to re-write userspace for multiple interfaces to the same > underlying ADC/DACs. > > I don't know how Greg feels about another subsystem in the kernel which > duplicates existing functionality/targetted devices - but it doesn't sound > like a good idea to me. > >>> I hope to meet you in person at fosdem and be able to talk over a beer >>> or two. >> >> Looking forward to meeting you :) > > Hopefully you can come to some logical conclusions over a friendly beverage. > Even if you can't decide on how to merge things (plan for adding missing > features from one to the other), maybe it's just deciding on how to get as > much reuse as possible (duplication of device register and bit definitions?) > I second these comments from Lars and Robin (or third I suppose ;). Lets get the best possible result. The source of an idea or code really doesn't matter in the long run, what matters is that we get a solution that works well for all users. Enjoy those beverages (and fosdem of course!) Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
