On 26.02.2021 16:40, Anton Ivanov wrote:
These are two different clients, then what you see is possible on NFS
with client side caching. If you have multiple clients reading/writing
to the same files you usually need to tune the caching options and/or
use locking. I suspect that if you leave it
it took me a while to correlate this) the logs it writes
have been truncated, but only while they're being observed on the
client, using tail -f or something like that.
Looks like this then:
On Server:
store01 /srv/export/home/users/timo/TestRun # ls -l slurm-41101.out
-rw-r--r-- 1 timo
Got a dmesg message on my AMD Renoir based Acer laptop:
"acer_wmi: Unknown key number - 0x84" when toggling keyboard
background light
Signed-off-by: Timo Witte
---
drivers/platform/x86/acer-wmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/acer-wmi.c
Zero the amount of padding bytes determined in perf_prepare_sample().
This prevents garbage being read from the ring buffer after it has wrapped
the page boundary at least once.
Signed-off-by: Timo Beckers
---
kernel/events/core.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions
*Timo Wischer*
Engineering Software Multimedia (ADITG/ESM)
Tel. +49 5121 49 6938
On 4/17/19 11:40 AM, Takashi Iwai wrote:
On Wed, 17 Apr 2019 11:30:10 +0200,
Timo Wischer wrote:
On 4/17/19 11:21, Takashi Iwai wrote:
On Wed, 17 Apr 2019 10:46:11 +0200,
wrote:
From: Timo Wischer
Since ARMv7
On 4/17/19 11:21, Takashi Iwai wrote:
On Wed, 17 Apr 2019 10:46:11 +0200,
wrote:
From: Timo Wischer
Since ARMv7 hardware cache coherence is supported.
"The SCU maintains coherency between the individual data caches in the
Cortex-A5 MPCore processor using a variation of the MOESI protoco
On 3/27/19 10:38, Takashi Iwai wrote:
On Wed, 27 Mar 2019 10:26:56 +0100,
Timo Wischer wrote:
On 3/27/19 10:11, Takashi Iwai wrote:
On Wed, 27 Mar 2019 09:34:40 +0100,
Timo Wischer wrote:
On 3/26/19 17:00, Takashi Iwai wrote:
On Tue, 26 Mar 2019 16:16:54 +0100,
Timo Wischer wrote:
On 3/26
On 3/27/19 10:11, Takashi Iwai wrote:
On Wed, 27 Mar 2019 09:34:40 +0100,
Timo Wischer wrote:
On 3/26/19 17:00, Takashi Iwai wrote:
On Tue, 26 Mar 2019 16:16:54 +0100,
Timo Wischer wrote:
On 3/26/19 15:23, Takashi Iwai wrote:
On Tue, 26 Mar 2019 12:25:37 +0100,
Timo Wischer wrote:
On 3/26
On 3/26/19 17:00, Takashi Iwai wrote:
On Tue, 26 Mar 2019 16:16:54 +0100,
Timo Wischer wrote:
On 3/26/19 15:23, Takashi Iwai wrote:
On Tue, 26 Mar 2019 12:25:37 +0100,
Timo Wischer wrote:
On 3/26/19 09:35, Takashi Iwai wrote:
On Tue, 26 Mar 2019 08:49:33 +0100,
wrote
On 3/26/19 15:23, Takashi Iwai wrote:
On Tue, 26 Mar 2019 12:25:37 +0100,
Timo Wischer wrote:
On 3/26/19 09:35, Takashi Iwai wrote:
On Tue, 26 Mar 2019 08:49:33 +0100,
wrote:
From: Timo Wischer
snd_pcm_link() can be called by the user as long as
On 3/25/19 17:58, Takashi Iwai wrote:
On Mon, 25 Mar 2019 17:40:23 +0100,
Timo Wischer wrote:
Best regards
Timo Wischer
Engineering Software Base (ADITG/ESB)
Tel. +49 5121 49 6938
On 3/25/19 17:07, Takashi Iwai wrote:
On Mon, 25 Mar 2019 17:00:38 +0100,
wrote:
From
struct i2c_adapter *adapter)
static const struct i2c_algorithm tegra_bpmp_i2c_algo = {
.master_xfer = tegra_bpmp_i2c_xfer,
+ .master_xfer_atomic = tegra_bpmp_i2c_xfer_atomic,
.functionality = tegra_bpmp_i2c_func,
};
Looks good to me.
Reviewed-by: Timo Alho
latform_device *pdev)
return err;
}
-static int tegra_bpmp_resume(struct device *dev)
+static int __maybe_unused tegra_bpmp_resume(struct device *dev)
{
struct tegra_bpmp *bpmp = dev_get_drvdata(dev);
unsigned int i;
Arnd, is this seen with 32-bit ARM configs?
Timo, does i
7;ping' to check that firmware is alive, or 'tag' to read the firmware
version).
BR,
Timo
ame and data to firmware via DRAM.
Signed-off-by: Timo Alho
---
Changes in v2:
- Address Jonathan's review feedback
* restructure error printing and what error codes passed to higher
layers
* don't use IS_ERR_OR_NULL()
* avoid overwriting last-character of filename in one cor
On 29.09.2017 17:53, Jonathan Hunter wrote:
On 29/09/17 14:46, Timo Alho wrote:
Hi Jon,
On 21.09.2017 14:21, Jonathan Hunter wrote:
On 07/09/17 10:31, Timo Alho wrote:
Check return code in BPMP response message(s). The typical error case
is when clock operation is attempted with invalid
On 29.09.2017 17:58, Jonathan Hunter wrote:
+static int bpmp_populate_dir(struct tegra_bpmp *bpmp, struct seqbuf
*seqbuf,
+ struct dentry *parent, uint32_t depth)
Do we need to use uint32_t here?
+{
+ int err;
+ uint32_t d, t;
And here?
It's part of the BPMP ABI th
Hi Jon,
On 21.09.2017 14:21, Jonathan Hunter wrote:
On 07/09/17 10:31, Timo Alho wrote:
Check return code in BPMP response message(s). The typical error case
is when clock operation is attempted with invalid clock identifier.
Also remove error print from call to clk_get_info() as the
dev, sz, virt, phys);
+out:
+ if (ret < 0)
+ debugfs_remove(root);
Should we have a generic warning message here? Looks like it could fail
silently.
I'll add a warning to call site (bpmp.c) if this fails.
-Timo
Add checks for return code in BPMP response message.
Signed-off-by: Timo Alho
---
drivers/reset/tegra/reset-bpmp.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/reset/tegra/reset-bpmp.c b/drivers/reset/tegra/reset-bpmp.c
index 5daf2ee..fac2db6 100644
--- a
this code and does not pass it to
caller. Fix this by adding an extra struct member to
tegra_bpmp_message and populate that with return code.
Signed-off-by: Timo Alho
---
drivers/firmware/tegra/bpmp.c | 22 --
include/soc/tegra/bpmp.h | 1 +
2 files changed, 17
out when the clock id is unused.
Signed-off-by: Timo Alho
---
drivers/clk/tegra/clk-bpmp.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c
index 638ace6..a896692 100644
--- a/drivers/clk/tegra/clk
,
Timo
Timo Alho (4):
firmware: tegra: propagate error code to caller
clk: tegra: check BPMP response return code
reset: tegra: check BPMP response return code
soc/tegra: bpmp: check BPMP response return code
drivers/clk/tegra/clk-bpmp.c | 15 ++-
drivers/firmware/tegra
Add checks for return code in BPMP response message.
Signed-off-by: Timo Alho
---
drivers/soc/tegra/powergate-bpmp.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/tegra/powergate-bpmp.c
b/drivers/soc/tegra/powergate-bpmp.c
index 8fc3560
ame and data to firmware via DRAM.
Signed-off-by: Timo Alho
---
drivers/firmware/tegra/Makefile | 4 +-
drivers/firmware/tegra/bpmp.c | 2 +
drivers/firmware/tegra/bpmp_debugfs.c | 446 ++
include/soc/tegra/bpmp.h | 14 ++
4 fil
d-off-by: Timo Alho
---
drivers/mmc/host/sdhci-tegra.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index f668a6f..cdde9ff 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -
Subdevices of bpmp, such as bpmp-i2c, require the bpmp device's
drvdata to be set during their probe. Currently this is not always the
case. Fix this by calling platform_set_drvdata() earlier during bpmp's
probe.
Signed-off-by: Timo Alho
---
drivers/firmware/tegra/bpmp.c | 4 ++
This patch fixes the following checkpatch.pl warning in prism2sta.h:
WARNING: Block comments should align the * on each line
No more warnings block comments warnings for this file.
Signed-off-by: Timo Schmid
---
drivers/staging/wlan-ng/prism2sta.c | 36 ++--
1
Hi,
Riku Voipio schrieb am 13.09.2016 10:22:
> On 5 September 2016 at 02:43, Timo Sigurdsson
> wrote:
>> The builddeb script has some hardcoded references to linux version 2.6
>> which is ancient. Use a variable instead in order to keep in sync with
>> new releas
The builddeb script has some hardcoded references to linux version 2.6
which is ancient. Use a variable instead in order to keep in sync with
new releases and avoid the need to manually update this. In addition,
change the copyright notice to include the year 2016.
Signed-off-by: Timo Sigurdsson
l now
turn off the USB power supply during boot by default if the driver isn't
present. (This was not the case in linux 4.3 or lower where the USB power
was always left on.)
Hence, add the driver to multi_v7_defconfig in order to keep USB support
working on those boards that require it.
Sign
Hi Arnd,
Arnd Bergmann schrieb am 31.12.2015 16:46:
> On Tuesday 29 December 2015 02:47:32 Timo Sigurdsson wrote:
>> Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if this
>> could make it into 4.4 in order to avoid unpleasent surprises (and
>> subse
Hi Maxime,
Maxime Ripard schrieb am 31.12.2015 17:00:
> Hi Arnd,
>
> On Thu, Dec 31, 2015 at 04:46:01PM +0100, Arnd Bergmann wrote:
>> On Tuesday 29 December 2015 02:47:32 Timo Sigurdsson wrote:
>> > Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if
newly added driver is required to power them.
Timo Sigurdsson (1):
ARM: Fix broken USB support in sunxi_defconfig
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
w turn off the USB power
supply during boot by default if the driver isn't present. (This was not the
case in linux 4.3 or lower where the USB power was always left on.)
Hence, add the driver to sunxi_defconfig in order to keep USB support working
on those boards that require it.
Sign
es of
CONFIG_KEYBOARD_SUN4I_LRADC and not have it removed while cleaning up
Good night,
Timo
Am Freitag, den 20.11.2015, 02:46 +0100 schrieb Timo Sigurdsson:
> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> framework") moved the the sunxi SID driver to a new framework, but l
e the line disabling CONFIG_KEYBOARD in
order to really enable KEYBOARD_SUN4I_LRADC.
Signed-off-by: Timo Sigurdsson
---
arch/arm/configs/sunxi_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 0bbc2ee..90252ca 10
ff-by: Timo Sigurdsson
---
arch/arm/configs/sunxi_defconfig | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 90252ca..95b51fc 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/co
_defconfig.
Signed-off-by: Timo Sigurdsson
---
arch/arm/configs/sunxi_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..0bbc2ee 100644
--- a/arch/arm/configs/sunxi_defconfig
+++
Sorry, sent out the reply first to Maxime only and forgot to include the
rest of the bunch. So, here we go again...
Hi Maxime,
Am Freitag, den 20.11.2015, 00:43 +0100 schrieb Maxime Ripard:
> Hi,
>
> On Thu, Nov 19, 2015 at 10:48:35PM +0100, Timo Sigurdsson wrote:
> > Hi Maxime,
Hi Maxime,
Hi Chen-Yu,
Am Dienstag, den 17.11.2015, 02:42 +0100 schrieb Timo Sigurdsson:
> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> framework") moved the the sunxi SID driver to a new framework, but left
> sunxi_defconfig with the depre
driver
in multi_v7_defconfig.
Signed-off-by: Timo Sigurdsson
---
Changes in v2:
- Move the extra cleanup work for multi_v7_defconfig to a separate
patch (to be submitted at a later point to avoid conflicts with
another patch waiting to be merged)
---
arch/arm/configs/multi_v7_defconfig | 3 ++-
1 file
tp://www.spinics.net/lists/dri-devel/msg93299.html
>>
>> I think the problem here is that I don't see this patch in linux-next
>> yet.
>>
>
> Indeed... and I don't know when it will go there so actually maybe it
> should be removed... but in the same time removing
Hi,
Lee Jones schrieb am 17.11.2015 09:07:
> On Tue, 17 Nov 2015, Timo Sigurdsson wrote:
>
>> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
>> framework") moved the the sunxi SID driver to a new framework, but left
>> multi_v7_defconfig
Hi,
Am Dienstag, den 17.11.2015, 11:10 +0900 schrieb Krzysztof Kozlowski:
> On 17.11.2015 10:49, Timo Sigurdsson wrote:
> > Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> > framework") moved the the sunxi SID driver to a new framework, but left
&g
driver
in multi_v7_defconfig.
While at it, clean up multi_v7_defconfig by generating a fresh file via
make multi_v7_defconfig
make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.
Signed-off-by: Timo Sigurdsson
diff -
_defconfig.
While at it, clean up sunxi_defconfig by generating a fresh file via
make sunxi_defconfig
make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.
Signed-off-by: Timo Sigurdsson
diff --git a/a
t the default voltages inherited by sun7i-a20.dtsi.
Signed-off-by: Timo Sigurdsson
---
Changes since v2:
- (Re)Added board-specific OPP after Kevin Hilman reported problems with
the default voltages at lower frequencies
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts
Hi Maxime,
Maxime Ripard schrieb am 07.10.2015 19:49:
> Hi Timo,
>
> On Wed, Oct 07, 2015 at 05:49:18PM +0200, Timo Sigurdsson wrote:
>> Hi Kevin,
>> Hi Maxime,
>>
>> Kevin Hilman schrieb am 07.10.2015 16:36:
>>
>> > "Timo Sigurdsson"
Hi Kevin,
Hi Maxime,
Kevin Hilman schrieb am 07.10.2015 16:36:
> "Timo Sigurdsson" writes:
>> I still think that the lower voltages may be the cause of your problem
>> with that specific board, so could you please test the attached patch on
>> top of my patch
Hi Kevin,
Kevin Hilman schrieb am 24.09.2015 19:57:
> kernelci.org started finding boot faiulres[1] on bananapi linux-next
> around next-20150918, but it was only failing in some labs and not
> others. I finally bisected it down to this patch, which landed in
> linux-next in the form of 2d665a8a8
Hi Kevin,
Kevin Hilman schrieb am 25. Sept 2015 01:57:
> On Tue, Aug 18, 2015 at 8:36 AM, Maxime Ripard
> wrote:
>> On Sun, Aug 02, 2015 at 06:18:25PM +0200, Timo Sigurdsson wrote:
>>> sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209
>>> P
x27;t
stable across all SoCs and boards out there.
Signed-off-by: Timo Sigurdsson
---
Changes since v1:
- Fixed checkpatch warnings
- Changed the commit message and title to clarify that this is not a
board-specific issue, but rather a limitation by the SoC
---
arch/arm/boot/dts/sun7i-a20.dts
. Am I
missing something? Is this not sufficient?
Thanks,
Timo
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun7i-a20-bananapi.dts?id=v4.2-rc5#n78
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Hi Maxime,
Maxime Ripard schrieb am 03.08.2015 11:34:
> On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote:
>> Julian Calaby schrieb am 03.08.2015 06:22:
>> > My only real objection here is are there boards that can go down to
>> > 0.9v and if so, won&#
Hi Maxime,
Maxime Ripard schrieb am 03.08.2015 11:13:
> On Sun, Aug 02, 2015 at 09:23:06PM +0200, Timo Sigurdsson wrote:
>> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20
>> boards
>> (or all?), however, do not allow the voltage to go below 1.0V
nd haven't found a way to read power consumption
internally via the PMU in mainline yet.
Thanks,
Timo
--
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/major
it make sense to modify the code that uses this
> to use frequencies with voltages specified that are lower than can be
> supplied with the lowest voltage it can?)
Considering OPPv2 is in the works, maybe not?
Thanks,
Timo
--
To unsubscribe from this list: send the line "unsubscribe lin
patch
today to fix this. [1] That might be a good place to discuss whether this
setting should be removed entirely.
Regards,
Timo
[1] https://groups.google.com/forum/#!topic/linux-sunxi/fIfbdn7mrQA
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards
(or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
voltage for the lowest operating point to 1.0V so all boards can actually use
it.
Signed-off-by: Timo Sigurdsson
---
arch/arm/boot/dts
sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt.
Signed-off-by: Timo Sigurdsson
---
Changes since v1 (RFC):
- Dropped the changes to the cpufreq operating points and renamed the patch
accord
Hi,
Hans de Goede schrieb am 28.07.2015 16:24:
> I've no problem with Timo submitting a cleaned up version of his
> patch and you taking that instead. I just wanted to point out that
> I do have a similar patch pending.
Ok, I will do that. It might take a couple of days, though
s
>> cannot handle the frequency regardless of the higher voltage.
>
> Agreed.
Ok, then I will write another patch for this as well, unless Chen-Yu or
someone else objects.
Regards,
Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
not rely on the userspace to be stable
> and harmless for the hardware. It should just work reliably by itself.
Same as above.
Regards,
Timo
--
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/
uldn't be discouraged by that. The only thing that
matters to me here is that regulator support will be added, regardless of
who submitted the patch. But anyway, I will rework the patch along the
statements made during this discussion.
Regards,
Timo
--
To unsubscribe from this list: send the
and I
> interpreted them.
IMHO for a common maximum opp that's a good approach. But for the lowest
frequency setting, it would seem more logical to me, to raise the voltage
to a point where all boards will run fine with them, unless those boards
cannot handle the frequency regardless of th
g maintainers should have a
common understanding on. I don't know how much variation there is among the
A20 boards in terms of frequencies and voltages. If there is a lot, I'd say
it would be desireable to have board-specific opp. The downside I see in my
approach is that it impacts
thing important?
Signed-off-by: Timo Sigurdsson
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 47 +---
1 file changed, 43 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..2bcbb0e 10
On 22.05.2015 13:46, Fu Wei wrote:
Hi Timo,
On 22 May 2015 at 16:59, Timo Kokkonen wrote:
On 22.05.2015 11:23, Fu Wei wrote:
Hi Timo,
On 22 May 2015 at 14:30, Timo Kokkonen wrote:
On 21.05.2015 11:32, fu@linaro.org wrote:
From: Fu Wei
Also update Documentation/watchdog
On 22.05.2015 11:23, Fu Wei wrote:
Hi Timo,
On 22 May 2015 at 14:30, Timo Kokkonen wrote:
On 21.05.2015 11:32, fu@linaro.org wrote:
From: Fu Wei
Also update Documentation/watchdog/watchdog-kernel-api.txt to
introduce:
(1)the new elements in the watchdog_device and watchdog_ops struct
uld be handled easily and maybe even so that other drivers
could have that feature even though their hardware does not explicitly
give any support for it.
Any thoughts?
Thanks,
-Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
ware that has
this kind of window definition, I'm sure there should be some kind of
software support for it too. I'm open to hear more about it.
-Timo
In my case I can only set 2 timouts (1sec and 2sec) but I need to support all 8
timeout
values.
The other thing is that my Watchdog
e pushed up to userspace. It feels
awkward to do it in the kernel, but users are apparently depending on
this behavior. Timo, do you mind sharing some more details about how
your scripts ran into the bug?
We are choosing the active subvolume via kernel command line parameter, eg:
root=/dev/mmcb
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93021
Reported-by: Timo Kokkonen
Fixes: bafc9b754f75 ("vfs: More precise tests in d_invalidate")
Signed-off-by: Omar Sandoval
Tested-by: Timo Kokkonen
Thank you
-Timo
---
This applies to 4.0-rc6. To be honest, I'm not sure that th
On Thu, 19 Dec 2013 16:02:19 +0100 (CET)
Jiri Kosina wrote:
> On Thu, 19 Dec 2013, Timo Teras wrote:
>
> > As you see, the main executable is mapped 5762-57708000 and
> > 57708000-5770a000. Heap follow immediately after that
> > 5770a000-5770c000 followed by anythin
On Thu, 19 Dec 2013 15:17:03 +0100 (CET)
Jiri Kosina wrote:
> On Wed, 2 Oct 2013, Timo Teräs wrote:
>
> > arch/*/include/asm/elf.h comments say:
> > ELF_ET_DYN_BASE is the location that an ET_DYN program is loaded
> > if exec'ed. Typical use of this is to invok
ull heap address space for PIE applications
and fixes random "out of memory" errors.
Signed-off-by: Timo Teräs
---
fs/binfmt_elf.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
It might make sense to define ELF_ET_DYN_APP_BASE or similar
so that architectures can specify
Hi,
It seems that ASLR with PIE binaries (linux-3.11.0-vanilla on ARM)
seems to create bad memory layout - the programs run out of memory
relatively soon, especially if they also mmap() lot of memory.
I believe the problem is that fs/binfmt_elf.c:load_elf_binary() sets
load_bias to 0 when CONFIG_
t/net/xfrm/xfrm_output.c?id=497574c72c9922cf20c12aed15313c389f722fa0
> >
> >
> > Hope it helps.
>
> Hi Fan, Jean,
>
> Thanks, that looks like it's the patch for exactly my problem.
> Unfortunately I can't test it until next week now. :-/
>
> Timo/Dave: are there any plans t
On Fri, 31 May 2013 10:08:27 -0300
Mauro Carvalho Chehab wrote:
> Em Thu, 30 May 2013 21:00:01 +0200
> Jon Arne Jørgensen escreveu:
>
> > On Thu, May 30, 2013 at 08:33:32AM +0300, Timo Teras wrote:
> > > I would rather have the platform_data provide the new table. Or
&g
t->dev.platform_data)
> + saa711x_writeregs(sd, saa7113_new_init);
> + else
> + saa711x_writeregs(sd, saa7113_init);
I would rather have the platform_data provide the new table. Or if you
think bulk of the table will be the same for most
[] ? __vmalloc_node_range+0x13e/0x15f
[] sys_init_module+0x62/0x77
[] syscall_call+0x7/0xb
EIP: [] __gpio_cansleep+0xe/0x1a SS:ESP 0068:cded9dbc
CR2: 004c
---[ end trace 5308fb20d2514822 ]---
Signed-off-by: Timo Teräs
Cc: Jingoo Han
Cc: Sachin Kamat
Cc: Raphael Assenat
Cc: Trent
I got the below with Linux 3.8.7-grsec and 3.9.2-grsec. Where as
3.6.11-grsec is a known good. I believe the same would happen on on
vanilla kernels too.
[ 15.709955] general protection fault: [#1] SMP
[ 15.712287] Modules linked in: leds_gpio(+) via_rhine mii cs5535_mfd mfd_core
geode_rng r
Masami Hiramatsu writes:
> Thank you for reporting!!
Thanks for fixing these! I spent some time trying to automate the
process of finding sensitive functions and eventually resorted into
booting a kvm instance with a minimal initrd to test every single
function in a clean and reproducible environ
On 03.14 2013 22:56:44, Arnd Bergmann wrote:
> This driver can be enabled on OMAP1 at the moment, which breaks
> allyesconfig for that platform. Let's mark it OMAP2PLUS-only
> in Kconfig, since that is the only thing it builds on.
>
Acked-by: Timo Kokkonen
Thanks!
>
Masami Hiramatsu writes:
> OK, then I'll update it to just use __always_inline.
I get a similar case of infinite recursion if I try to kprobe
"inat_get_opcode_attribute":
PID: 3028 TASK: 88003c67e8c0 CPU: 1 COMMAND: "insmod"
#0 [88003d60b9b8] __schedule at 813777f8
#1 [fff
my free time for doing
this, my RX51 device is not enumerating the USB with the latest kernel
and I haven't figured out that yet. And because of that, I haven't
been able to get my user space running over nfsroot setup I've been
using..
-Timo
> > > --- a/arch/arm/plat
Masami Hiramatsu writes:
>> I am unable to recreate this problem on a fedora system; hash_64 is
>> inlined AFAICS.
Thanks testing. How does the disassembly of get_kprobes look for you?
> I also tried and couldn't recreate hash_64 problem on my ubuntu 12.10.
> Could you tell us your kconfig?
Sur
There is a long-standing problem in the systemtap community where
accidentally kprobing a delicate function causes the system to crash:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604453
http://sourceware.org/bugzilla/show_bug.cgi?id=2725
https://bugzilla.redhat.com/show_bug.cgi?id=655904
ht
c_unregister_driver(lirc_rx51_driver.minor);
> }
>
> struct platform_driver lirc_rx51_platform_driver = {
> .probe = lirc_rx51_probe,
> - .remove = __exit_p(lirc_rx51_remove),
> + .remove = lirc_rx51_remove,
> .suspend= lir
rocesses fighting their turn to get CPU time. And once they get their
job done, they are all idling and waiting for the next event
(decompress and draw frame) to happen.
Even though the CPU is idle for half of the spent time, it is busy
running multiple processes during the other half. That way the
Heip!
I did something like "dd if=/dev/sda1 bs=256M of=dump" and the whole system
hanged after a while.
Netconsole captured following soft lockup:
===cut
BUG: soft lockup - CPU#3 stuck for 11s! [metalog:4767]
CPU 3:
Modules linked in: fglrx(P) cinergyT2
Pid: 4767, comm: metalog Tainted: P
Heip!
I recently moved to 64-bit kernel, but mixed sounds (ie. mpegs played with
a media player) don't work with optical S/PDIF connection. AC3/DTS
passthrough still works, and I can hear the mixed sounds on analog
connector. And yes, I have unmuted the IEC958 mixer setting.
Tested kernels:
Fully reproducible with me. v2.6.23.1 x86-64 SMP kernel, Core 2 CPU, gdb
v6.6.90.20070912-debian.
gdb ./hang
run
fr 1
p (char*)base
p command hangs and the entire system becomes unusably slow. kill -9
doesn't kill gdb.
/* gcc hang.c -o hang -g -Wall */
#include
#include
#include
#include
#in
Is there a reason why this isn't allowed now?
---
fs/fcntl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 8685263..fc0c92e 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -203,7 +203,7 @@ asmlinkage long sys_dup(unsigned int fildes)
r
When GRE tunnel is in NBMA mode, this patch allows an application to use
a PF_PACKET socket to:
- send a packet to specific NBMA address with sendto()
- use recvfrom() to receive packet and check which NBMA address it came from
Signed-off-by: Timo Teras <[EMAIL PROTECTED]>
---
This is
On Mon, 1 Oct 2007, Linus Torvalds wrote:
> So there's a final -rc out there, and right now my plan is to make this
> series really short, and release 2.6.23 in a few days. So please do give
> it a last good testing, and holler about any issues you find!
The r8169 nic performance regression is
806 Mbits/sec
//T
> Good night.
// /
....Timo Jantunen ..
ZZZ (Used to represent :Kuunsäde 8 A 28: Email: [EMAIL PROTECTED] :
the sound of a person snoring.) :FIN-02210 Espoo: http://iki.fi/jeti :
Webster's Enc
On Wed, 26 Sep 2007, Willy Tarreau wrote:
> On Wed, Sep 26, 2007 at 09:52:02PM +0300, Timo Jantunen wrote:
> > On Wed, 26 Sep 2007, Francois Romieu wrote:
> > > The patch below is scheduled for inclusion before 2.6.23. Please try it
> > > and
> > > see if it
On Wed, 26 Sep 2007, Francois Romieu wrote:
> The patch below is scheduled for inclusion before 2.6.23. Please try it and
> see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be welcome
> too).
Thanks for the quick reply and fix. Unfortunately the fix didn't help in my
case.
Ip
1 - 100 of 138 matches
Mail list logo
