The same .config, BIOS, and kernel boot parameters in both kernels.
# perf top -v
┌─Error:┐
│Failed to mmap with 12 (Cannot allocate memory)│
mmap size 528384B
[0.015080] smpboot: CPU0: AMD Ryzen 5 1600X Six-Core Processor
4.4 kernel had working [non-crashing] shrink_slab and friends...
x86_64 arch , Core i5 2500K, 16 GiB.
kernel: BUG: unable to handle kernel paging request at 00020157
kernel: IP: [] __lock_acquire.isra.15+0x39a/0x930
kernel: PGD 0
kernel:
kernel: Oops: [#1] PREEMPT SMP
kernel:
4.4 kernel had working [non-crashing] shrink_slab and friends...
x86_64 arch , Core i5 2500K, 16 GiB.
kernel: BUG: unable to handle kernel paging request at 00020157
kernel: IP: [] __lock_acquire.isra.15+0x39a/0x930
kernel: PGD 0
kernel:
kernel: Oops: [#1] PREEMPT SMP
kernel:
On Tue, Jan 10, 2017 at 10:22:41 +0100, Michal Hocko wrote:
> On Mon 09-01-17 23:02:10, Sami Farin wrote:
> > # sysctl vm.vfs_cache_pressure=-100
> >
> > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to
> > delete nr=-6640827866535449472
>
On Tue, Jan 10, 2017 at 10:22:41 +0100, Michal Hocko wrote:
> On Mon 09-01-17 23:02:10, Sami Farin wrote:
> > # sysctl vm.vfs_cache_pressure=-100
> >
> > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to
> > delete nr=-6640827866535449472
>
# sysctl vm.vfs_cache_pressure=-100
kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to
delete nr=-6640827866535449472
kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to
delete nr=-6640827866535450112
kernel: vmscan: shrink_slab:
# sysctl vm.vfs_cache_pressure=-100
kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to
delete nr=-6640827866535449472
kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to
delete nr=-6640827866535450112
kernel: vmscan: shrink_slab:
In write_pool(), isn't cond_resched() needed after call to
add_entropy_words() because otherwise there can be large latencies
(think of command "dd if=/dev/zero of=/dev/random bs=1" ) ?
--
Do what you love because life is too short for anything else.
-
To unsubscribe from this list:
In write_pool(), isn't cond_resched() needed after call to
add_entropy_words() because otherwise there can be large latencies
(think of command dd if=/dev/zero of=/dev/random bs=1 ) ?
--
Do what you love because life is too short for anything else.
-
To unsubscribe from this list: send
On Tue, Nov 20, 2007 at 13:52:52 +0100, Alessandro Suardi wrote:
> On Nov 20, 2007 7:52 AM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> > On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
> > >
> > > This one is definitely messy. There is absolutely no way to know what
> > > gcc has
On Tue, Nov 20, 2007 at 13:52:52 +0100, Alessandro Suardi wrote:
On Nov 20, 2007 7:52 AM, Herbert Xu [EMAIL PROTECTED] wrote:
On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
This one is definitely messy. There is absolutely no way to know what
gcc has miscompiled. It
On Fri, Sep 14, 2007 at 20:17:46 +0300, Sami Farin wrote:
> On Wed, Sep 05, 2007 at 18:48:51 -0400, Rik van Riel wrote:
> > Sami Farin wrote:
> >> On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote:
> >> ...
> >>>> *shrug*
> >>> Th
On Fri, Sep 14, 2007 at 20:17:46 +0300, Sami Farin wrote:
On Wed, Sep 05, 2007 at 18:48:51 -0400, Rik van Riel wrote:
Sami Farin wrote:
On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote:
...
*shrug*
The attached patch should make sure kswapd does not free an
excessive number
On Thu, Oct 25, 2007 at 16:46:26 +0200, Jiri Kosina wrote:
> On Thu, 25 Oct 2007, Arjan van de Ven wrote:
>
> > > Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
> > > worked in a predictable way:
> > this isn't a valid case afaics; even on "traditional x86" (before we
> >
Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
worked in a predictable way:
$ gcc brk.c -fPIC -pie -m64;./a.out;./a.out;./a.out
sbrk=0x7f721b815000 main=0x7f721af04860
sbrk succeeded (brk=0x7f721b909240)
sbrk=0x7fc3d77e2000 main=0x7fc3d66fa860
sbrk failed: Cannot allocate memory
Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
worked in a predictable way:
$ gcc brk.c -fPIC -pie -m64;./a.out;./a.out;./a.out
sbrk=0x7f721b815000 main=0x7f721af04860
sbrk succeeded (brk=0x7f721b909240)
sbrk=0x7fc3d77e2000 main=0x7fc3d66fa860
sbrk failed: Cannot allocate memory
On Thu, Oct 25, 2007 at 16:46:26 +0200, Jiri Kosina wrote:
On Thu, 25 Oct 2007, Arjan van de Ven wrote:
Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
worked in a predictable way:
this isn't a valid case afaics; even on traditional x86 (before we
changed the address
On Tue, Oct 23, 2007 at 18:13:21 +0200, Philippe Elie wrote:
> On Tue, 23 Oct 2007 at 13:10 +0000, Sami Farin wrote:
>
> > On Mon, Oct 22, 2007 at 19:38:10 -0700, Linus Torvalds wrote:
> > >
> > > This set of two patches look ok by me, but I'd like
On Mon, Oct 22, 2007 at 19:38:10 -0700, Linus Torvalds wrote:
>
> This set of two patches look ok by me, but I'd like sign-offs.. Also, were
> they tested and found to fix the problem by Sami?
>
> Linus
The previous patch I tested by Philippe, oprof-fix-profile_pc-use.patch,
On Mon, Oct 22, 2007 at 19:38:10 -0700, Linus Torvalds wrote:
This set of two patches look ok by me, but I'd like sign-offs.. Also, were
they tested and found to fix the problem by Sami?
Linus
The previous patch I tested by Philippe, oprof-fix-profile_pc-use.patch,
worked
On Tue, Oct 23, 2007 at 18:13:21 +0200, Philippe Elie wrote:
On Tue, 23 Oct 2007 at 13:10 +, Sami Farin wrote:
On Mon, Oct 22, 2007 at 19:38:10 -0700, Linus Torvalds wrote:
This set of two patches look ok by me, but I'd like sign-offs.. Also,
were
they tested and found
On Thu, Oct 11, 2007 at 16:36:10 +0200, Philippe Elie wrote:
> On Sat, 29 Sep 2007 at 20:05 +0000, Sami Farin wrote:
>
> > > x86_64 SMP kernel v2.6.22.6 (not using callgraph).
> > > sometimes oprofile works for a longer time... but not this time.
> > >
>
On Thu, Oct 11, 2007 at 16:36:10 +0200, Philippe Elie wrote:
On Sat, 29 Sep 2007 at 20:05 +, Sami Farin wrote:
x86_64 SMP kernel v2.6.22.6 (not using callgraph).
sometimes oprofile works for a longer time... but not this time.
2007-09-22 13:53:32.52723 1[ 3372.390188
On Mon, Oct 01, 2007 at 12:29:18 +0200, Andi Kleen wrote:
> Sami Farin <[EMAIL PROTECTED]> writes:
...
> Can you reproduce it with a non tainted kernel without any patches like CFS
> applied?
I tried without CFS and it Oopsed just as nicely,
the only difference was that in ca
On Mon, Oct 01, 2007 at 12:29:18 +0200, Andi Kleen wrote:
Sami Farin [EMAIL PROTECTED] writes:
...
Can you reproduce it with a non tainted kernel without any patches like CFS
applied?
I tried without CFS and it Oopsed just as nicely,
the only difference was that in call trace before
On Sat, Sep 22, 2007 at 14:23:35 +0300, Sami Farin wrote:
> x86_64 SMP kernel v2.6.22.6 (not using callgraph).
> sometimes oprofile works for a longer time... but not this time.
>
> 2007-09-22 13:53:32.52723 <1>[ 3372.390188] Unable to handle kernel NULL
>
On Sat, Sep 22, 2007 at 14:23:35 +0300, Sami Farin wrote:
x86_64 SMP kernel v2.6.22.6 (not using callgraph).
sometimes oprofile works for a longer time... but not this time.
2007-09-22 13:53:32.52723 1[ 3372.390188] Unable to handle kernel NULL
pointer dereference at 0650
x86_64 SMP kernel v2.6.22.6 (not using callgraph).
sometimes oprofile works for a longer time... but not this time.
2007-09-22 13:53:32.52723 <1>[ 3372.390188] Unable to handle kernel NULL
pointer dereference at 0650 RIP:
2007-09-22 13:53:32.527245948 <1>[ 3372.390195] []
x86_64 SMP kernel v2.6.22.6 (not using callgraph).
sometimes oprofile works for a longer time... but not this time.
2007-09-22 13:53:32.52723 1[ 3372.390188] Unable to handle kernel NULL
pointer dereference at 0650 RIP:
2007-09-22 13:53:32.527245948 1[ 3372.390195]
/var/log # grep -Ei "hpet|tsc" dmesg-2.6.19.7 dmesg.2.6.22.6-x86_64
dmesg-2.6.19.7:ACPI: HPET (v001 INTEL DQ965GF 0x15db MSFT 0x0113) @
0x3e6f2000
dmesg-2.6.19.7:ACPI: HPET id: 0x8086a201 base: 0xfed0
dmesg-2.6.19.7:[ 34.337155] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
/var/log # grep -Ei hpet|tsc dmesg-2.6.19.7 dmesg.2.6.22.6-x86_64
dmesg-2.6.19.7:ACPI: HPET (v001 INTEL DQ965GF 0x15db MSFT 0x0113) @
0x3e6f2000
dmesg-2.6.19.7:ACPI: HPET id: 0x8086a201 base: 0xfed0
dmesg-2.6.19.7:[ 34.337155] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
On Wed, Sep 05, 2007 at 18:48:51 -0400, Rik van Riel wrote:
> Sami Farin wrote:
>> On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote:
>> ...
>>>> *shrug*
>>> The attached patch should make sure kswapd does not free an
>>> excessive number of pa
On Wed, Sep 05, 2007 at 18:48:51 -0400, Rik van Riel wrote:
Sami Farin wrote:
On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote:
...
*shrug*
The attached patch should make sure kswapd does not free an
excessive number of pages in zone_normal just because the
pages in zone_highmem
On Tue, Sep 11, 2007 at 14:38:13 -0400, Lee Revell wrote:
> You can also diff -Nru old.c new.c | xclip, select Preformat, then
> paste with the middle button.
mutt does not come with text editor, so
I'd like to add note about vim:
If using xclip, type command
:set paste
before middle button or
On Tue, Sep 11, 2007 at 14:38:13 -0400, Lee Revell wrote:
You can also diff -Nru old.c new.c | xclip, select Preformat, then
paste with the middle button.
mutt does not come with text editor, so
I'd like to add note about vim:
If using xclip, type command
:set paste
before middle button or
On Mon, Sep 10, 2007 at 14:39:34 +0100, Alan Cox wrote:
...
> > Well, outpipe-village-512-1.bc.nu is NXDOMAIN.
> > It should have A record 81.2.110.250.
>
> I've yet to see a specification which requires this.
You don't need specs.
My point was you might have better luck emailing people
if you
On Mon, Sep 10, 2007 at 13:59:12 +0100, Alan Cox wrote:
> Will RMK ([EMAIL PROTECTED]) please fix his email setup otherwise I
> can't send serial/tty/arm stuff to him.
>
> "<<< 550 You have no reverse DNS; please try again when you have resolved
Well, outpipe-village-512-1.bc.nu is NXDOMAIN.
It
On Mon, Sep 10, 2007 at 13:59:12 +0100, Alan Cox wrote:
Will RMK ([EMAIL PROTECTED]) please fix his email setup otherwise I
can't send serial/tty/arm stuff to him.
550 You have no reverse DNS; please try again when you have resolved
Well, outpipe-village-512-1.bc.nu is NXDOMAIN.
It should
On Mon, Sep 10, 2007 at 14:39:34 +0100, Alan Cox wrote:
...
Well, outpipe-village-512-1.bc.nu is NXDOMAIN.
It should have A record 81.2.110.250.
I've yet to see a specification which requires this.
You don't need specs.
My point was you might have better luck emailing people
if you have
On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote:
...
>> *shrug*
>
> The attached patch should make sure kswapd does not free an
> excessive number of pages in zone_normal just because the
> pages in zone_highmem are difficult to free.
>
> It does give kswapd a large margin to continue
On Tue, Sep 04, 2007 at 21:37:35 -0400, Rik van Riel wrote:
> Sami Farin wrote:
>> Using SMP kernel 2.6.22.6pre-CFS-v20.5 on Pentium D (IA-32).
>> I think this bug (or whatever you want to call it) got triggered
>> when you first allocate several megabytes of memo
On Tue, Sep 04, 2007 at 21:37:35 -0400, Rik van Riel wrote:
Sami Farin wrote:
Using SMP kernel 2.6.22.6pre-CFS-v20.5 on Pentium D (IA-32).
I think this bug (or whatever you want to call it) got triggered
when you first allocate several megabytes of memory in a kernel module
and then free them
On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote:
...
*shrug*
The attached patch should make sure kswapd does not free an
excessive number of pages in zone_normal just because the
pages in zone_highmem are difficult to free.
It does give kswapd a large margin to continue putting
Using SMP kernel 2.6.22.6pre-CFS-v20.5 on Pentium D (IA-32).
I think this bug (or whatever you want to call it) got triggered
when you first allocate several megabytes of memory in a kernel module
and then free them, and then run e.g. X and when memory gets tight,
you end up with this situation...
Using SMP kernel 2.6.22.6pre-CFS-v20.5 on Pentium D (IA-32).
I think this bug (or whatever you want to call it) got triggered
when you first allocate several megabytes of memory in a kernel module
and then free them, and then run e.g. X and when memory gets tight,
you end up with this situation...
On Wed, Aug 22, 2007 at 17:09:04 +0200, Thomas Jarosch wrote:
> Hello,
>
> > > kernel BUG at arch/i386/mm/highmem.c:38
> > >
> > > Try this.
>
> I just tried kernel 2.6.22.4 and 2.6.23-rc3. Using 2.6.23-rc3 vanilla,
> the box survives only 3 seconds with ipt_CRASH. Here's the backtrace,
> it's
On Wed, Aug 22, 2007 at 17:09:04 +0200, Thomas Jarosch wrote:
Hello,
kernel BUG at arch/i386/mm/highmem.c:38
Try this.
I just tried kernel 2.6.22.4 and 2.6.23-rc3. Using 2.6.23-rc3 vanilla,
the box survives only 3 seconds with ipt_CRASH. Here's the backtrace,
it's only slightly
After I got this error [1], system got real slow, like 386 having 32 MB of RAM
and swapping constantly.
My system is P4 SMP with 1GB of RAM.
I got this same behavior with 2.6.19, too, but then I used GNU cp v6.9
which had micro-optimization which did not bother doing read() for regular
files,
After I got this error [1], system got real slow, like 386 having 32 MB of RAM
and swapping constantly.
My system is P4 SMP with 1GB of RAM.
I got this same behavior with 2.6.19, too, but then I used GNU cp v6.9
which had micro-optimization which did not bother doing read() for regular
files,
On Tue, Mar 27, 2007 at 09:40:23 -0400, Stephen Smalley wrote:
> On Tue, 2007-03-27 at 13:06 +0300, Sami Farin wrote:
> > is there room for improvement in security_port_sid() ?
>
> Yes, lots of room. Also, it won't get called per-packet if you enable
> secmark (echo 0 >
is there room for improvement in security_port_sid() ?
little test with dns queries (dnsfilter (the client) on local host
using poll() and dnscache (the server) using epoll (at max 4000 concurrent
queries):
(stats for only vmlinux)
CPU: P4 / Xeon, speed 2797.32 MHz (estimated)
Counted
is there room for improvement in security_port_sid() ?
little test with dns queries (dnsfilter (the client) on local host
using poll() and dnscache (the server) using epoll (at max 4000 concurrent
queries):
(stats for only vmlinux)
CPU: P4 / Xeon, speed 2797.32 MHz (estimated)
Counted
On Tue, Mar 27, 2007 at 09:40:23 -0400, Stephen Smalley wrote:
On Tue, 2007-03-27 at 13:06 +0300, Sami Farin wrote:
is there room for improvement in security_port_sid() ?
Yes, lots of room. Also, it won't get called per-packet if you enable
secmark (echo 0 /selinux/compat_net or boot
Not sure if this is oprofile's fault, but I got this
when I started opreport.
10 min after BUG system needed to be rebooted (cycling power).
With earlier kernel (without oprofile) everything worked for a month
without hiccups.
[295318.822839] BUG: unable to handle kernel NULL pointer dereference
Not sure if this is oprofile's fault, but I got this
when I started opreport.
10 min after BUG system needed to be rebooted (cycling power).
With earlier kernel (without oprofile) everything worked for a month
without hiccups.
[295318.822839] BUG: unable to handle kernel NULL pointer dereference
On Wed, Mar 07, 2007 at 00:24:35 +0200, Sami Farin wrote:
> On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote:
> ...
> > And I found bug in gcc-4.1.2, it gave 0 for ncubic results
> > when doing 1000 loops test... gcc-4.0.3 works.
>
> Found it.
>
> --- cbrt
On Wed, Mar 07, 2007 at 00:24:35 +0200, Sami Farin wrote:
On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote:
...
And I found bug in gcc-4.1.2, it gave 0 for ncubic results
when doing 1000 loops test... gcc-4.0.3 works.
Found it.
--- cbrt-test.c~ 2007-03-07 00:20
On Tue, Mar 06, 2007 at 21:20:33 +0100, Eric Dumazet wrote:
...
> I rewrote the reciprocal_div() for i386 so that one multiply is used.
>
> static inline u32 reciprocal_divide(u32 A, u32 R)
> {
> #if __i386
> unsigned int edx, eax;
> asm("mul %2":"=a" (eax), "=d" (edx):"rm" (R),
On Wed, Mar 07, 2007 at 11:11:49 -0500, Chuck Ebbert wrote:
> Sami Farin wrote:
> > On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote:
> > ...
> >> And I found bug in gcc-4.1.2, it gave 0 for ncubic results
> >> when doing 1000 loops test..
On Tue, Mar 06, 2007 at 21:20:33 +0100, Eric Dumazet wrote:
...
I rewrote the reciprocal_div() for i386 so that one multiply is used.
static inline u32 reciprocal_divide(u32 A, u32 R)
{
#if __i386
unsigned int edx, eax;
asm(mul %2:=a (eax), =d (edx):rm (R), 0 (A));
On Wed, Mar 07, 2007 at 11:11:49 -0500, Chuck Ebbert wrote:
Sami Farin wrote:
On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote:
...
And I found bug in gcc-4.1.2, it gave 0 for ncubic results
when doing 1000 loops test... gcc-4.0.3 works.
Found it.
--- cbrt-test.c
On Tue, Mar 06, 2007 at 16:00:55 -0800, Stephen Hemminger wrote:
...
> > Now Linux 2.6 does not have "memory" in fls, maybe it causes
> > some gcc funnies some people are seeing.
> >
>
> That code was copy-paste from:
> include/asm-x86_64/bitops.h
>
> So shouldn't both fls() and ffs() be
On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote:
...
> And I found bug in gcc-4.1.2, it gave 0 for ncubic results
> when doing 1000 loops test... gcc-4.0.3 works.
Found it.
--- cbrt-test.c~2007-03-07 00:20:54.735248105 +0200
+++ cbrt-test.c 2007-03-07 00:21:03.964864343
On Tue, Mar 06, 2007 at 10:29:41 -0800, Stephen Hemminger wrote:
> Don't count the existing Newton-Raphson out. It turns out that to get enough
> precision for 32 bits, only 4 iterations are needed. By unrolling those, it
> gets much better timing.
>
> Slightly gross test program (with original
On Tue, Mar 06, 2007 at 16:00:55 -0800, Stephen Hemminger wrote:
...
Now Linux 2.6 does not have memory in fls, maybe it causes
some gcc funnies some people are seeing.
That code was copy-paste from:
include/asm-x86_64/bitops.h
So shouldn't both fls() and ffs() be fixed there
On Tue, Mar 06, 2007 at 10:29:41 -0800, Stephen Hemminger wrote:
Don't count the existing Newton-Raphson out. It turns out that to get enough
precision for 32 bits, only 4 iterations are needed. By unrolling those, it
gets much better timing.
Slightly gross test program (with original cubic
On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote:
...
And I found bug in gcc-4.1.2, it gave 0 for ncubic results
when doing 1000 loops test... gcc-4.0.3 works.
Found it.
--- cbrt-test.c~2007-03-07 00:20:54.735248105 +0200
+++ cbrt-test.c 2007-03-07 00:21:03.964864343 +0200
On Fri, Feb 23, 2007 at 17:05:27 -0800, Stephen Hemminger wrote:
> Since there already two users of full 64 bit division in the kernel,
> and other places maybe hiding out as well. Add a full 64/64 bit divide.
>
> Yes this expensive, but there are places where it is necessary.
> It is not clear
On Fri, Feb 23, 2007 at 17:05:27 -0800, Stephen Hemminger wrote:
Since there already two users of full 64 bit division in the kernel,
and other places maybe hiding out as well. Add a full 64/64 bit divide.
Yes this expensive, but there are places where it is necessary.
It is not clear if
I setup namespace for /tmp and /var/tmp
( pam_namespace.so into /etc/pam.d/{su,login} )
and something did not like something I did:
[322593.844838] 0x0: 00 00 00 00 2b 00 00 11 20 21 00 00 00 68 ff ff
[322593.844854] Filesystem "sda8": XFS internal error xfs_da_do_buf(2) at line
2087 of file
I setup namespace for /tmp and /var/tmp
( pam_namespace.so into /etc/pam.d/{su,login} )
and something did not like something I did:
[322593.844838] 0x0: 00 00 00 00 2b 00 00 11 20 21 00 00 00 68 ff ff
[322593.844854] Filesystem sda8: XFS internal error xfs_da_do_buf(2) at line
2087 of file
On Wed, Jan 17, 2007 at 14:43:29 +1100, David Chinner wrote:
...
> > > Subject: BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS)
> > > References : http://lkml.org/lkml/2007/1/5/308
> > > Submitter : Sami Farin <[EMAIL PROTECTED]>
> > > Ha
On Wed, Jan 17, 2007 at 14:43:29 +1100, David Chinner wrote:
...
Subject: BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS)
References : http://lkml.org/lkml/2007/1/5/308
Submitter : Sami Farin [EMAIL PROTECTED]
Handled-By : David Chinner [EMAIL PROTECTED]
Status
On Tue, Jan 16, 2007 at 14:57:56 +0100, Jan Engelhardt wrote:
>
> >Subject: Re: I broke my port numbers :(
> >
> >On Mon, Jan 15, 2007 at 23:55:15 +0200, Sami Farin wrote:
> >> I know this may be entirely my fault but I have tried reversing
> >> all of
On Tue, Jan 16, 2007 at 14:57:56 +0100, Jan Engelhardt wrote:
Subject: Re: I broke my port numbers :(
On Mon, Jan 15, 2007 at 23:55:15 +0200, Sami Farin wrote:
I know this may be entirely my fault but I have tried reversing
all of my _own_ patches I applied to 2.6.19.2 but can't find
On Mon, Jan 15, 2007 at 23:55:15 +0200, Sami Farin wrote:
> I know this may be entirely my fault but I have tried reversing
> all of my _own_ patches I applied to 2.6.19.2 but can't find what broke this.
> I did three times "netcat 127.0.0.69 42", notice the different
> port
I know this may be entirely my fault but I have tried reversing
all of my _own_ patches I applied to 2.6.19.2 but can't find what broke this.
I did three times "netcat 127.0.0.69 42", notice the different
port numbers.
First, if someone could attempt this on 2.6.19.2 or 2.6.20-rc* ,
and tell it
I know this may be entirely my fault but I have tried reversing
all of my _own_ patches I applied to 2.6.19.2 but can't find what broke this.
I did three times netcat 127.0.0.69 42, notice the different
port numbers.
First, if someone could attempt this on 2.6.19.2 or 2.6.20-rc* ,
and tell it
On Mon, Jan 15, 2007 at 23:55:15 +0200, Sami Farin wrote:
I know this may be entirely my fault but I have tried reversing
all of my _own_ patches I applied to 2.6.19.2 but can't find what broke this.
I did three times netcat 127.0.0.69 42, notice the different
port numbers.
Hmm... when I do
On Tue, Jan 09, 2007 at 17:48:04 -0800, Auke Kok wrote:
> Sami Farin wrote:
> >On Tue, Jan 09, 2007 at 15:59:30 -0800, Auke Kok wrote:
> >>Sami Farin wrote:
> >...
> >>>I do "ethtool -K eth0 tso off" now and check if I get the hang again. =)
>
On Tue, Jan 09, 2007 at 15:59:30 -0800, Auke Kok wrote:
> Sami Farin wrote:
...
> >I do "ethtool -K eth0 tso off" now and check if I get the hang again. =)
>
> I'm unsure whether v7.2.x already automatically disables TSO for 100mbit
> speed link, probably not. It s
Linux 2.6.19.1 SMP on Pentium D, Intel DQ965GF mobo.
Got this while bittorrenting knoppix:
2007-01-09 22:53:40.020693500 <4>NETFILTER drop IN=eth0 OUT=
MAC=00:19:d1:00:5f:01:00:05:00:1c:58:1c:08:00 SRC=83.46.5.76 DST=80.223.106.128
LEN=121 TOS=0x00 PREC=0x00 TTL=112 ID=53273 PROTO=ICMP TYPE=3
Linux 2.6.19.1 SMP on Pentium D, Intel DQ965GF mobo.
Got this while bittorrenting knoppix:
2007-01-09 22:53:40.020693500 4NETFILTER drop IN=eth0 OUT=
MAC=00:19:d1:00:5f:01:00:05:00:1c:58:1c:08:00 SRC=83.46.5.76 DST=80.223.106.128
LEN=121 TOS=0x00 PREC=0x00 TTL=112 ID=53273 PROTO=ICMP TYPE=3
On Tue, Jan 09, 2007 at 15:59:30 -0800, Auke Kok wrote:
Sami Farin wrote:
...
I do ethtool -K eth0 tso off now and check if I get the hang again. =)
I'm unsure whether v7.2.x already automatically disables TSO for 100mbit
speed link, probably not. It should.
It disabled it but I enabled
On Tue, Jan 09, 2007 at 17:48:04 -0800, Auke Kok wrote:
Sami Farin wrote:
On Tue, Jan 09, 2007 at 15:59:30 -0800, Auke Kok wrote:
Sami Farin wrote:
...
I do ethtool -K eth0 tso off now and check if I get the hang again. =)
I'm unsure whether v7.2.x already automatically disables TSO
On Mon, Jan 08, 2007 at 10:04:36 +1100, David Chinner wrote:
> On Sun, Jan 07, 2007 at 02:48:12PM -0800, Andrew Morton wrote:
> > On Mon, 8 Jan 2007 09:23:41 +1100
> > David Chinner <[EMAIL PROTECTED]> wrote:
> >
> > > How are you supposed to invalidate a range of pages in a mapping for
> > >
On Mon, Jan 08, 2007 at 08:37:34 +1100, David Chinner wrote:
...
> > fstab was there just fine after -u.
>
> Oh, that still hasn't been fixed?
Looked like it =)
> Generic bug, not XFS - the global
> semaphore->mutex cleanup converted the bd_mount_sem to a mutex, and
> mutexes complain loudly
On Mon, Jan 08, 2007 at 08:37:34 +1100, David Chinner wrote:
...
fstab was there just fine after -u.
Oh, that still hasn't been fixed?
Looked like it =)
Generic bug, not XFS - the global
semaphore-mutex cleanup converted the bd_mount_sem to a mutex, and
mutexes complain loudly when a the
On Mon, Jan 08, 2007 at 10:04:36 +1100, David Chinner wrote:
On Sun, Jan 07, 2007 at 02:48:12PM -0800, Andrew Morton wrote:
On Mon, 8 Jan 2007 09:23:41 +1100
David Chinner [EMAIL PROTECTED] wrote:
How are you supposed to invalidate a range of pages in a mapping for
this case, then?
On Sat, Jan 06, 2007 at 21:11:07 +, Hugh Dickins wrote:
> On Sat, 6 Jan 2007, Sami Farin wrote:
>
> > Linux 2.6.19.1 SMP [2] on Pentium D...
> > I was running dt-15.14 [2] and I ran
> > "cinfo datafile" (it does mincore()).
> > Well it went OK but when
On Sat, Jan 06, 2007 at 21:11:07 +, Hugh Dickins wrote:
On Sat, 6 Jan 2007, Sami Farin wrote:
Linux 2.6.19.1 SMP [2] on Pentium D...
I was running dt-15.14 [2] and I ran
cinfo datafile (it does mincore()).
Well it went OK but when I ran strace cinfo datafile...:
04:18:48.062466
On Sat, Jan 06, 2007 at 04:39:07 +0200, Sami Farin wrote:
> Linux 2.6.19.1 SMP [2] on Pentium D...
> I was running dt-15.14 [2] and I ran
> "cinfo datafile" (it does mincore()).
> Well it went OK but when I ran "strace cinfo datafile"...:
> 04:18:48.062466 minco
Linux 2.6.19.1 SMP [2] on Pentium D...
I was running dt-15.14 [2] and I ran
"cinfo datafile" (it does mincore()).
Well it went OK but when I ran "strace cinfo datafile"...:
04:18:48.062466 mincore(0x37f1f000, 2147266560,
...
2007-01-06 04:19:03.788181500 <4>BUG: warning at
Linux 2.6.19.1 SMP [2] on Pentium D...
I was running dt-15.14 [2] and I ran
cinfo datafile (it does mincore()).
Well it went OK but when I ran strace cinfo datafile...:
04:18:48.062466 mincore(0x37f1f000, 2147266560,
...
2007-01-06 04:19:03.788181500 4BUG: warning at
On Sat, Jan 06, 2007 at 04:39:07 +0200, Sami Farin wrote:
Linux 2.6.19.1 SMP [2] on Pentium D...
I was running dt-15.14 [2] and I ran
cinfo datafile (it does mincore()).
Well it went OK but when I ran strace cinfo datafile...:
04:18:48.062466 mincore(0x37f1f000, 2147266560,
Forgot to do git
On Thu, Jan 04, 2007 at 16:03:34 -0800, Andrew Morton wrote:
> On Fri, 5 Jan 2007 00:26:42 +0200
> Sami Farin <[EMAIL PROTECTED]> wrote:
>
> > Kernel 2.6.19.1 SMP on Pentium D. I ran command restorecon -R /wrk.
> > After a while or two programs stopped res
Kernel 2.6.19.1 SMP on Pentium D. I ran command restorecon -R /wrk.
After a while or two programs stopped responding and I had to reboot.
I'm not sure is this bug or feature...
I upgraded selinux policy before running restorecon.
2007-01-04 22:41:55.360538500 <4>softlimit D 61707865 0
Kernel 2.6.19.1 SMP on Pentium D. I ran command restorecon -R /wrk.
After a while or two programs stopped responding and I had to reboot.
I'm not sure is this bug or feature...
I upgraded selinux policy before running restorecon.
2007-01-04 22:41:55.360538500 4softlimit D 61707865 0
On Thu, Jan 04, 2007 at 16:03:34 -0800, Andrew Morton wrote:
On Fri, 5 Jan 2007 00:26:42 +0200
Sami Farin [EMAIL PROTECTED] wrote:
Kernel 2.6.19.1 SMP on Pentium D. I ran command restorecon -R /wrk.
After a while or two programs stopped responding and I had to reboot.
I'm not sure
just a simple test I did...
xfs_freeze -f /mnt/newtest
cp /etc/fstab /mnt/newtest
xfs_freeze -u /mnt/newtest
2007-01-04 01:44:30.341979500 <4>BUG: warning at
kernel/mutex-debug.c:80/debug_mutex_unlock()
2007-01-04 01:44:30.385771500 <4> [] dump_trace+0x215/0x21a
2007-01-04 01:44:30.385774500 <4>
1 - 100 of 115 matches
Mail list logo
