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/majordomo-info.ht
he 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 linux-kernel" in
the bo
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/majordomo-info.html
Please read the FAQ at http
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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
s. [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 a message to majord...@v
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
accordingly
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 public_tim...@silentcreek.de
---
Changes since v1 (RFC):
- Dropped the changes to the cpufreq operating points and renamed
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 public_tim
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 a message to majord...@vger.kernel.org
More majordomo info at http
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, tho
>> 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 body o
ss 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/
uraged 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 line "unsubscr
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 the hig
mmon 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 readability of the dts(i) files when settings
of the dts(i) files when settings
are overridden further down the tree.
Thanks and 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
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 the higher voltage.
Regards,
Timo
--
To unsubscribe from this list: send
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 body of a message to majord...@vger.kernel.org
More majordomo
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, as I will be moving
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 line unsubscribe linux-kernel in
the body
to use that setting, it's easier to
limit the maximum in userspace compared to compiling a new device
tree blob.
Except that the kernel should 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
?
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 100644
--- a/arch
?
Signed-off-by: Timo Sigurdsson public_tim...@silentcreek.de
---
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
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
ld 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 message to
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 message to majord
On 22.05.2015 11:23, Fu Wei wrote:
Hi Timo,
On 22 May 2015 at 14:30, Timo Kokkonen timo.kokko...@offcode.fi wrote:
On 21.05.2015 11:32, fu@linaro.org wrote:
From: Fu Wei fu@linaro.org
Also update Documentation/watchdog/watchdog-kernel-api.txt to
introduce:
(1)the new elements
On 22.05.2015 13:46, Fu Wei wrote:
Hi Timo,
On 22 May 2015 at 16:59, Timo Kokkonen timo.kokko...@offcode.fi wrote:
On 22.05.2015 11:23, Fu Wei wrote:
Hi Timo,
On 22 May 2015 at 14:30, Timo Kokkonen timo.kokko...@offcode.fi wrote:
On 21.05.2015 11:32, fu@linaro.org wrote:
From: Fu
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 can have differen timeout values de
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 can have differen timeout values depending
on the CPLD and the customer requirements. I can not read out this values
e 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/mmcblk0p3 rw rootwait rootflags=subvol=/foobar
In the user sp
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/mmcblk0p3 rw rootwait rootflags=subvol=/foobar
In the user space we run a script that does some upgrades
lla: 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 this is
://bugzilla.kernel.org/show_bug.cgi?id=93021
Reported-by: Timo Kokkonen timo.kokko...@offcode.fi
Fixes: bafc9b754f75 (vfs: More precise tests in d_invalidate)
Signed-off-by: Omar Sandoval osan...@osandov.com
Tested-by: Timo Kokkonen timo.kokko...@offcode.fi
Thank you
-Timo
---
This applies to 4.0-rc6
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
On Thu, 19 Dec 2013 15:17:03 +0100 (CET)
Jiri Kosina jkos...@suse.cz 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 invoke ./ld.so someprog
On Thu, 19 Dec 2013 16:02:19 +0100 (CET)
Jiri Kosina jkos...@suse.cz 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 anything mmaped after
ddress 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 the load
applications
and fixes random out of memory errors.
Signed-off-by: Timo Teräs timo.te...@iki.fi
---
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 the load address of ET_DYN
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
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
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 to push thi
=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 to push this into 3.10-rc and/or
stable? I seem to be able to hit the issue pretty
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
On Fri, 31 May 2013 10:08:27 -0300
Mauro Carvalho Chehab mche...@redhat.com wrote:
Em Thu, 30 May 2013 21:00:01 +0200
Jon Arne Jørgensen jona...@jonarne.no 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
v.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 users, then perhaps
add there an enum saying which table to use - and name the tables
according to the chip variant it applies to.
- 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
[] ? __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
] __gpio_cansleep+0xe/0x1a SS:ESP 0068:cded9dbc
CR2: 004c
---[ end trace 5308fb20d2514822 ]---
Signed-off-by: Timo Teräs timo.teras@iki.f
Cc: Jingoo Han jg1@samsung.com
Cc: Sachin Kamat sachin.ka...@linaro.org
Cc: Raphael Assenat r...@8d.com
Cc: Trent Piepho tpie...@freescale.com
Cc
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
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
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
Masami Hiramatsu masami.hiramatsu...@hitachi.com 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
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!
> Sign
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 timo.t.kokko...@iki.fi
Thanks!
Signed
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
Masami Hiramatsu masami.hiramatsu...@hitachi.com 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
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-omap/dmtimer.c
> > > +++ b/arch/arm
space running over nfsroot setup I've been
using..
-Timo
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -333,6 +333,14 @@ int omap_dm_timer_get_irq(struct omap_dm_timer
*timer)
}
EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
+struct clk
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?
Masami Hiramatsu masami.hiramatsu...@hitachi.com 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
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
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
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
= {
.probe = lirc_rx51_probe,
- .remove = __exit_p(lirc_rx51_remove),
+ .remove = lirc_rx51_remove,
.suspend= lirc_rx51_suspend,
.resume = lirc_rx51_resume,
.driver = {
For ir-rx51:
Acked-by: Timo Kokkonen timo.t.kokko
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 average
load is higher than what one would expect
on the average CPU
consumption.
-Timo
I've also seen a situation where vlc has been using close to 90%
CPU, plays flawlessly, yet the load average reports as 1.5 - if the
load average is more than 1, then that should mean there is
insufficient system bandwidth to sustain the running jobs in real
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 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:
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
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 stdio.h
#include string.h
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)
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)
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
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 useful
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
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 Encyclop
//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 Encyclopedic Unabridged
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.
Heip!
(commit: "r8169: merge with version 6.001.00 of Realtek's r8169 driver")
In current 2.6.23-rc8 snapshot r8169 send performance is bad, around
32MB/s. In 2.6.22 it was around 83MB/s. Interestingly, the receive
performance has increased from around 85MB/s to 96MB/s at the same time!
Git
Heip!
(commit: r8169: merge with version 6.001.00 of Realtek's r8169 driver)
In current 2.6.23-rc8 snapshot r8169 send performance is bad, around
32MB/s. In 2.6.22 it was around 83MB/s. Interestingly, the receive
performance has increased from around 85MB/s to 96MB/s at the same time!
Git
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.
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 makes a difference on top of 2.6.23-rc8 (full
on the
same nic.
This patch moves the printk's out of the spinlock protected area.
Without this patch the machine hangs hard. With this patch everything still
works even when there is significant increase on CPU usage while using the
nic.
//T
Signed-off-by: Timo Jantunen <[EMAIL PROTECTED]>
on the
same nic.
This patch moves the printk's out of the spinlock protected area.
Without this patch the machine hangs hard. With this patch everything still
works even when there is significant increase on CPU usage while using the
nic.
//T
Signed-off-by: Timo Jantunen [EMAIL PROTECTED]
diff
On Fri, 3 Aug 2007, Andrew Morton wrote:
> On Thu, 2 Aug 2007 11:57:21 +0300 (EEST)
> Timo Jantunen <[EMAIL PROTECTED]> wrote:
>
> > Heip!
> >
> > I have had few total hangs with 2.6.22.1 kernel. Everything suddenly
> > freezes and nothing work
On Fri, 3 Aug 2007, Andrew Morton wrote:
On Thu, 2 Aug 2007 11:57:21 +0300 (EEST)
Timo Jantunen [EMAIL PROTECTED] wrote:
Heip!
I have had few total hangs with 2.6.22.1 kernel. Everything suddenly
freezes and nothing works (SysRq keys, pinging the machine from the
network
Heip!
I have had few total hangs with 2.6.22.1 kernel. Everything suddenly
freezes and nothing works (SysRq keys, pinging the machine from the
network.) Neither syslog nor netconsole have any relevant messages. I'm 99%
sure this didn't happen in 2.6.21.x kernels.
All hangs happened with
Heip!
I have had few total hangs with 2.6.22.1 kernel. Everything suddenly
freezes and nothing works (SysRq keys, pinging the machine from the
network.) Neither syslog nor netconsole have any relevant messages. I'm 99%
sure this didn't happen in 2.6.21.x kernels.
All hangs happened with
To sum this up:
the userspace 2.6.20.6 (the "good" kernel) and 2.6.22 (the "bad" kernel)
were compiled in is exactly the same setup. I recompiled "good" to check
for that, earlier, but "good" also works then.
"good" does not exhibit the printks I placed in the section (the same
ones I did for
David Brownell wrote:
> On Thursday 12 July 2007, Satyam Sharma wrote:
>
> Note that hangs in that file almost always mean "your BIOS is goofy".
> Hunt for BIOS settings related to USB, and change them.
This laptop's BIOS only offers "legacy support" enabled or disabled,
both of which lead to
David Brownell wrote:
On Thursday 12 July 2007, Satyam Sharma wrote:
Note that hangs in that file almost always mean your BIOS is goofy.
Hunt for BIOS settings related to USB, and change them.
This laptop's BIOS only offers legacy support enabled or disabled,
both of which lead to frozen
To sum this up:
the userspace 2.6.20.6 (the good kernel) and 2.6.22 (the bad kernel)
were compiled in is exactly the same setup. I recompiled good to check
for that, earlier, but good also works then.
good does not exhibit the printks I placed in the section (the same
ones I did for bad), making
101 - 200 of 261 matches
Mail list logo
