On Thu, Dec 17, 2020 at 12:21 AM Bjorn Helgaas wrote:
>
> On Wed, Dec 16, 2020 at 12:20:53PM +0100, Ian Kumlien wrote:
> > On Wed, Dec 16, 2020 at 1:08 AM Bjorn Helgaas wrote:
> > > On Tue, Dec 15, 2020 at 02:09:12PM +0100, Ian Kumlien wrote:
> > > > On Tue, Dec
On Wed, Dec 16, 2020 at 1:08 AM Bjorn Helgaas wrote:
>
> On Tue, Dec 15, 2020 at 02:09:12PM +0100, Ian Kumlien wrote:
> > On Tue, Dec 15, 2020 at 1:40 AM Bjorn Helgaas wrote:
> > >
> > > On Mon, Dec 14, 2020 at 11:56:31PM +0100, Ian Kumlien wrote:
> > >
On Tue, Dec 15, 2020 at 1:40 AM Bjorn Helgaas wrote:
>
> On Mon, Dec 14, 2020 at 11:56:31PM +0100, Ian Kumlien wrote:
> > On Mon, Dec 14, 2020 at 8:19 PM Bjorn Helgaas wrote:
>
> > > If you're interested, you could probably unload the Realtek drivers,
> >
On Mon, Dec 14, 2020 at 8:19 PM Bjorn Helgaas wrote:
>
> On Mon, Dec 14, 2020 at 04:47:32PM +0100, Ian Kumlien wrote:
> > On Mon, Dec 14, 2020 at 3:02 PM Bjorn Helgaas wrote:
> > > On Mon, Dec 14, 2020 at 10:14:18AM +0100, Ian Kumlien wrote:
> > > > On Mon, Dec
On Mon, Dec 14, 2020 at 3:02 PM Bjorn Helgaas wrote:
>
> On Mon, Dec 14, 2020 at 10:14:18AM +0100, Ian Kumlien wrote:
> > On Mon, Dec 14, 2020 at 6:44 AM Bjorn Helgaas wrote:
> > >
> > > [+cc Jesse, Tony, David, Jakub, Heiner, lists in case there's an ASPM
&g
ormance, but AFAICT the devices in that path give us
> no reason to disable L1. If I understand the spec correctly, the
> Realtek device should not be relevant to the I211 path.]
>
> On Sun, Dec 13, 2020 at 10:39:53PM +0100, Ian Kumlien wrote:
> > On Sun, Dec 13, 2020 at 12:47 AM
On Thu, Oct 8, 2020 at 6:19 AM Kai-Heng Feng
wrote:
>
>
>
> > On Oct 7, 2020, at 21:30, Bjorn Helgaas wrote:
> >
> > On Wed, Oct 07, 2020 at 12:26:19PM +0800, Kai-Heng Feng wrote:
> >>> On Oct 6, 2020, at 03:19, Bjorn Helgaas wrote:
> >>> On Tue, Oct 06, 2020 at 02:40:32AM +0800, Kai-Heng Feng w
On Wed, Oct 7, 2020 at 3:30 PM Bjorn Helgaas wrote:
>
> On Wed, Oct 07, 2020 at 12:26:19PM +0800, Kai-Heng Feng wrote:
> > > On Oct 6, 2020, at 03:19, Bjorn Helgaas wrote:
> > > On Tue, Oct 06, 2020 at 02:40:32AM +0800, Kai-Heng Feng wrote:
> > >>> On Oct 3, 2020, at 06:18, Bjorn Helgaas wrote:
On Wed, Oct 7, 2020 at 6:26 AM Kai-Heng Feng
wrote:
>
>
>
> > On Oct 6, 2020, at 03:19, Bjorn Helgaas wrote:
> >
> > [+cc Ian, who's also working on an ASPM issue]
> >
> > On Tue, Oct 06, 2020 at 02:40:32AM +0800, Kai-Heng Feng wrote:
> >>> On Oct 3, 2020, at 06:18, Bjorn Helgaas wrote:
> >>> On
;latency_up.l1, link->latency_dw.l1);
- if ((link->aspm_capable & ASPM_STATE_L1) &&
- (latency + l1_switch_latency > acceptable->l1))
- link->aspm_capable &= ~ASPM_STATE_L1;
- l1_switch_latency += 1000;
+ if (link->a
On Mon, Jan 21, 2019 at 7:48 PM David Miller wrote:
>
> From: Ian Kumlien
> Date: Mon, 21 Jan 2019 16:38:11 +0100
>
> > Hi David,
> >
> > could we have your blessing to add the following patch to -stable for
> > 4.20.4:
> > commit 41d1c8839e5f8cb781cc63
id S. Miller
---
Also, do you keep your -stable queue somewhere where I can see it?
It feels like I'm stepping on toes, adding overhead and such, which is
not what i want...
On Mon, Jan 21, 2019 at 4:10 PM Greg KH wrote:
> On Mon, Jan 21, 2019 at 03:56:24PM +0100, Ian Kumlien wrote:
On Mon, Jan 21, 2019 at 3:47 PM Greg KH wrote:
>
> On Mon, Jan 21, 2019 at 03:44:24PM +0100, Ian Kumlien wrote:
> > Hi,
> >
> > IMHO you are missing: 41d1c8839e5f8cb781cc635f12791decee8271b7
> >
> > Which should be marked for stable, it fixes:
> > h
Hi,
IMHO you are missing: 41d1c8839e5f8cb781cc635f12791decee8271b7
Which should be marked for stable, it fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=202235
On Fri, Jan 11, 2019 at 10:35 AM Eric Dumazet wrote:
> On Thu, Jan 10, 2019 at 12:55 AM Paolo Abeni wrote:
> > On Thu, 2019-01-10 at 09:25 +0100, Ian Kumlien wrote:
>
>
> > > This works, and so does:
> > > https://marc.info/?l=linux-netdev&m=154696956604748
On Thu, Jan 10, 2019 at 6:53 AM Eric Dumazet wrote:
> On Wed, Jan 9, 2019 at 4:48 PM Ian Kumlien wrote:
> >
> > Hi,
> >
> > Just been trough ~5+ hours of bisecting and eventually actually found
> > the culprit =)
> >
> > commit fb420d5d91c1
Hi,
Just been trough ~5+ hours of bisecting and eventually actually found
the culprit =)
commit fb420d5d91c1274d5966917725e71f27ed092a85 (refs/bisect/bad)
Author: Eric Dumazet
Date: Fri Sep 28 10:28:44 2018 -0700
tcp/fq: move back to CLOCK_MONOTONIC
[--8<--]
So this might be because my
Confirmed, sending a new mail with summary etc
On Thu, Jan 10, 2019 at 1:16 AM Ian Kumlien wrote:
>
> On Wed, Jan 9, 2019 at 12:17 AM Ian Kumlien wrote:
> > On Wed, Jan 9, 2019, 00:09 Florian Fainelli
> [--8<---]
>
> >> > when looking at "git log v4.
On Wed, Jan 9, 2019 at 12:17 AM Ian Kumlien wrote:
> On Wed, Jan 9, 2019, 00:09 Florian Fainelli > > when looking at "git log v4.19...v4.20
>> > drivers/net/ethernet/intel/ixgbe/" nothing else really stands out...
>> > The machine is also running NAT for my ho
On Tue, Jan 8, 2019 at 11:51 PM Stephen Hemminger
wrote:
> On Tue, 8 Jan 2019 23:10:04 +0100
> Ian Kumlien wrote:
> > On Sun, Jan 6, 2019 at 11:21 PM Ian Kumlien wrote:
> > >
> > > [Sorry for the repost, screwed up the netdev address...]
> > >
> > &g
On Sun, Jan 6, 2019 at 11:21 PM Ian Kumlien wrote:
>
> [Sorry for the repost, screwed up the netdev address...]
>
> Hi,
>
> Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s.
>
> My firewall (which also runs the dhcpd) runs VM:s and it doe
[Sorry for the repost, screwed up the netdev address...]
Hi,
Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s.
My firewall (which also runs the dhcpd) runs VM:s and it does this by
having physical
interfaces attached to bridges - which the VM:s in turn attach to.
Since 4.2
Hi,
Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s.
My firewall (which also runs the dhcpd) runs VM:s and it does this by
having physical
interfaces attached to bridges - which the VM:s in turn attach to.
Since 4.20 the VM:s can't use DHCP, it's odd since the requests are
No response? Should pcc_cpufreq be assumed as broken since it actually
kills machines?
Should I submit a patch that removes it?
On Tue, Nov 20, 2018 at 3:05 PM Ian Kumlien wrote:
>
> Hi,
>
> We've had this happen a few times now, pcc_cpufreq is loaded and the
> machine
Hi,
We've had this happen a few times now, pcc_cpufreq is loaded and the
machine has a LA of 33 with kworkers consuming *all CPU*
We have had this happen before, looking at it has been pushed to the
leaky-stack^tm in my mind and...
32 cores:
processor : 31
vendor_id : GenuineIntel
cpu family : 6
Hi,
I just had this happen a little while ago, got different weird
deadlocks but this one actually generated a oops..
This is basic operation, a machine with 16 gb memory mainly doing NFS traffic.
I'm currently playing with RDMA for this, which is why mlx4 is included.
When the crash occurs, th
Hi,
While restarting a docker container today we had four machines
deadlock with the following oops
If this is related to propagate_one, then nothing has changed in the
later kernels and this could still be a issue
I'm still trying to investigate what happened
This is the OCR-corrected version:
80
Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
Signed-off-by: Ian Kumlien
---
net/core/flow_dissector.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..
80
Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
Signed-off-by: Ian Kumlien
---
net/core/flow_dissector.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..
On Mon, Jan 2, 2017 at 5:07 AM, David Miller wrote:
> From: Ian Kumlien
> Date: Mon, 2 Jan 2017 00:19:36 +0100
>
>> __skb_flow_dissect can be called with a skb or a data packet, either
>> can be NULL. All calls seems to have been moved to __skb_header_pointer
>> exc
00080
---
Signed-off-by: Ian Kumlien
---
net/core/flow_dissector.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
nhoff + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;
Will send a patch with signed off by n' all.
On Sun, Jan 1, 2017 at 6:31 PM, Ian Kumlien
On Fri, Dec 30, 2016 at 11:48 PM, Ian Kumlien wrote:
> Hi,
>
> Been fighting with "crash" to get it to help me to analyze my crash
> dumps... This is the output from vmcore-dmesg.
>
> This is 100% reproducible...
>
> Config that lets the connec
Hi,
Been fighting with "crash" to get it to help me to analyze my crash
dumps... This is the output from vmcore-dmesg.
This is 100% reproducible...
Config that lets the connection trough but crashes the kernel:
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_NAT_PPTP is not set
CONFIG_PPTP=y
On 22 February 2016 at 01:38, Ian Kumlien wrote:
> Hi,
>
> When i tried to upgrade my, soon to be, firewall to 4.5-rc5 to do some
> testing - it deadlocked almost instantly.
After bisect, the offending patch seems to be:
b16c29191dc89bd877af99a7b04ce4866728a3e0
It looks like some
Hi,
When i tried to upgrade my, soon to be, firewall to 4.5-rc5 to do some
testing - it deadlocked almost instantly.
In the photo, i started writing "root" and it keeps repeating it, like
it's in a while loop.
https://goo.gl/photos/yGhNSogJjeb2VJyu5
Trying to get better information - as in any
After a few hours the machine started to spontaneously reboot.
It's back to running 4.2.5 - which works fine.
(I don't know if these messages are actually reaching lkml since it's
not showing up in the index on marc.info)
On 4 November 2015 at 10:24, Ian Kumlien wrote:
> Hi,
Hi,
This happened when i booted linux 4.3 on a old intel machine.
Please note, it's named before "twilight" was known and it's name is
inspired by "twilight zone" since it's actually a firewall ;)
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
1666 root 20 0
Sending this to both netdev and kernel since i don't know if it's the
driver or the pcie AER that does something odd - the machine was
stable before 3.19 and PCIE AER.
Everything started out like i first sent to linux nics () intel:
--
And today i had some issues and wondered why things was b
Hi,
Sorry to but in like this but I'm suffering from the same kind of
deadlocks with nouveau...
The really odd thing is that i could boot some -rc6+ kernel without
problems but it hung
while playing video and then it refused to start properly again.
Anyway, to quote Maarten:
Ok that most likely
Hi,
I have to admit that this is perhaps not the best time to write this,
late in the evening after work but... =)
A friend of mine recently started to develop things on Linux and got a
bit confused since Linux lacks PTHREAD_SCOPE_PROCESS which just about
all other OS:es seems to implement.
(Ok,
On Fri, Aug 1, 2014 at 3:16 PM, Imre Deak wrote:
[--8<--]
> Ok, I see the trace of suspend/resume now, but the bug has vanished.. I
> can't see the WARN backtrace in your original report, nor the debug
> message from the above fix, that would indicate that it had fixed
> anything ("VDD left on b
On fre, 2014-07-25 at 12:28 +0300, Imre Deak wrote:
> On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote:
> > Try four, now including CC lists for the intel driver...
>
> Could you give a try to the 2 patches at:
> https://patchwork.kernel.org/patch/4437061/
>
> If t
dicated that there might be two more missing...)
commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien
Date: Tue Jul 22 21:10:50 2014 +0200
Add intel_display_power_get before _put
When closing the lid when using 3.16-rc6 on my laptop i got
three &qu
sing...)
commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien
Date: Tue Jul 22 21:10:50 2014 +0200
Add intel_display_power_get before _put
When closing the lid when using 3.16-rc6 on my laptop i got
three "WARN_ON" back traces.
Example:
[ 9064
ssing...)
commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien
Date: Tue Jul 22 21:10:50 2014 +0200
Add intel_display_power_get before _put
When closing the lid when using 3.16-rc6 on my laptop i got
three "WARN_ON" back traces.
Example:
[ 9064.008821] WARNING: CPU:
On tis, 2014-07-22 at 12:20 -0700, Randy Dunlap wrote:
> On 07/22/2014 12:03 PM, Ian Kumlien wrote:
> > This is a resend, try two...
> >
> > And while the fix is simple, something along the lines of:
> > diff --git a/fs/direct-io.c b/fs/direct-io.c
> > index 980
On tis, 2014-07-22 at 21:12 +0200, Richard Weinberger wrote:
> On Tue, Jul 22, 2014 at 9:03 PM, Ian Kumlien wrote:
> > This is a resend, try two...
>
> Please see "[PATCH v3] direct-io: fix uninitialized warning in
> do_direct_IO()".
That looks like a better approac
to);
if (IS_ERR(page)) {
ret = PTR_ERR(page);
---
I however don't know if it's in the correct C standard, it compiles fine
though... (or if this is more gcc speific)
commit f94d05ce10d869c418d3271bd028fc33bfd25e6f
Author: Ian Kumlien
Date:
On ons, 2014-01-22 at 11:52 +1100, NeilBrown wrote:
> On Mon, 20 Jan 2014 19:27:18 +0100 Ian Kumlien wrote:
> > I have been unable to trip this up, so this was it!
> >
> > Tested-by: Ian Kumlien
> >
> > I hope this hits stable ASAP ;)
>
> I've
.
>
> The important aspect of the patch is that it moves the "atomic_inc" of
> "sh->count" back under the protection of ->device_lock in the case when some
> other thread might be using the same 'sh'.
I have been unable to trip this up, so this
On mån, 2014-01-20 at 14:37 +1100, NeilBrown wrote:
> On Mon, 20 Jan 2014 01:49:17 +0100 Ian Kumlien wrote:
>
> > On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote:
> > > On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien
> > > wrote:
> > >
> >
On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote:
> On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien wrote:
>
> > Ok, so third try to actually email this...
> > ---
> >
> > Hi,
> >
> > I started testing 3.13-rc8 on another machine since t
Ok, so third try to actually email this...
---
Hi,
I started testing 3.13-rc8 on another machine since the first one seemed
to be working fine...
One spontaneous reboot later i'm not so sure ;)
Right now i captured a kernel oops in the raid code it seems...
(Also attached to avoid mangling)
On Fri, Nov 15, 2013 at 05:44:26PM -0500, David Miller wrote:
> From: Bjorn Helgaas
> Date: Fri, 15 Nov 2013 15:29:53 -0700
>
> > [+cc David, Eric, Alex, netdev]
> >
> > Alex reported a similar issue at
> > http://marc.info/?l=linux-netdev&m=138355719901790&w=4
>
> Fixed by:
>
> commit 84502b5
Hi,
After a lot of wondering i finally tracked down the bug that was hitting
me since 3.12-rc7. Since this is a firewall I haven't actually noticed
it all the time. But when i saw that it rebooted too often, i enabled
netconsole and this is the output:
BUG: unable to handle kernel NULL pointer d
Hi all,
I have a atl1c networking card in my laptop - it's not connected since i
use wifi instead.
After a while of uptime it seems like it goes haywire, tools are
currently reporting data transfers of ~9GB/s
ifconfig eth0
eth0: flags=4099 mtu 1500
ether 48:5b:39:5e:b0:4b txqueuelen 1
On tor, 2012-11-29 at 20:25 +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 05:24:03PM +0100, Ian Kumlien wrote:
> > > Can you do:
> > >
> > > make arch/x86/kernel/ptrace.lst
> > >
> > > and send me that file, privately is fine to
On Thu, Nov 29, 2012 at 03:22:20PM +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 01:27:08PM +0100, Ian Kumlien wrote:
> > I think that chrome does traceing all the time as a part of it's
> > sandbox - this is most likely chrome monitoring flash...
>
> Ah, ok
On Thu, Nov 29, 2012 at 10:26:21AM +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 12:20:02AM +0100, Ian Kumlien wrote:
> > Hi,
> >
> > Due to unexplained dns problems, I'll be using google plus to post the
> > photo of the bug output.
> &g
someone who has these things handled ;)
--
Ian Kumlien -- http://demius.net || http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
From lkml:
On Tue, 27 Nov 2007 23:40:22 +0100
Ian Kumlien <[EMAIL PROTECTED]> wrote:
> [Repost, no reply has been recived]
>
> Hi,
>
> A little while ago, something went horribly wrong.
>
> I could still use my mouse and the desktop was still alive more or
> less.
: transmit ring 442 .. 461 report=442 done=442
NETDEV WATCHDOG: eth0: transmit timed out
sky2 eth0: tx timeout
sky2 eth0: transmit ring 442 .. 461 report=442 done=442
And it continues until i press the reset button.
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is
Hi,
I have some similar problems on a completely unrelated system, but i
still wonder.
When you untar, which filesystem do you untar too?
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
On tis, 2007-11-20 at 15:13 +1100, Nick Piggin wrote:
> On Tuesday 20 November 2007 11:59, Ian Kumlien wrote:
> > Hi,
> >
> > I have had this before and sent a mail about it.
> >
> > It seems like the diskcache is still in use and is never shrunk. This
&g
524208 pages of RAM
10149 reserved pages
5189 pages shared
8 pages swap cached
Out of memory: kill process 8352 (gnome-session) score 361583 or a child
Killed process 8399 (metacity)
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
On ons, 2007-10-03 at 14:04 -0400, Bill Davidsen wrote:
> Ian Kumlien wrote:
> > On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
> >> Remove unneeded check that caused problems with jumbo frame sizes.
> >> The check was recently added and is wrong.
> >&
On tis, 2007-10-02 at 21:59 -0700, Stephen Hemminger wrote:
> On Wed, 03 Oct 2007 03:34:34 +0200
> Ian Kumlien <[EMAIL PROTECTED]> wrote:
>
> > On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
> > > Remove unneeded check that caused problems with jumbo fr
orking.
Now running with 9k mtu with no errors, =)
It also seems that the FIFO bug was the one that affected me before,
damn odd race that one.
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Tested-by: Ian Kumlien <[EMAIL PROTECTED]>
(if that tag exists now)
Btw, Sorry b
now when jumbo frames work again, just mail me patches =)
(to tired to look in to it closer atm)
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
On ons, 2007-09-05 at 05:45 -0700, Andrew Morton wrote:
> > On Wed, 05 Sep 2007 03:28:07 +0200 Ian Kumlien <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I have just had a quite unexpected 'low memory situation'...
> >
> > This is a AMD6
wa
0 1 393904 16108 13788 158337221 2296798 4 2
92 2
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
On mån, 2007-07-16 at 21:56 +0200, Jens Axboe wrote:
> On Mon, Jul 16 2007, Ian Kumlien wrote:
> > On mån, 2007-07-16 at 19:29 +0200, Jens Axboe wrote:
> > > On Mon, Jul 16 2007, Chuck Ebbert wrote:
> > > > On 07/15/2007 11:20 AM, Ian Kumlien wrote:
> > >
On mån, 2007-07-16 at 19:29 +0200, Jens Axboe wrote:
> On Mon, Jul 16 2007, Chuck Ebbert wrote:
> > On 07/15/2007 11:20 AM, Ian Kumlien wrote:
> > > I had emerge --sync failing several times...
> > >
> > > So i checked dmesg and found some info, attached furt
rker_thread+0xb2/0xc0
[] autoremove_wake_function+0x0/0x40
[] kthread+0x38/0x60
[] kthread+0x0/0x60
[] kernel_thread_helper+0x7/0x10
===========
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
k_start_queueing+0x11/0x20
[] as_work_handler+0xf/0x20
[] run_workqueue+0x6b/0xe0
[] worker_thread+0x0/0xc0
[] worker_thread+0xb2/0xc0
[] autoremove_wake_function+0x0/0x40
[] kthread+0x38/0x60
[] kthread+0x0/0x60
[] kernel_thread_helper+0x7/0x10
=======
--
Ian
t=413 done=413
sky2 eth0: transmit ring 320 .. 279 report=320 done=320
Else, they are all off by 41.
Is this a known bug?
Comments? ideas?
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
--
Ian Ku
table when the entries array is
> cleared, so that we don't have "pre-inserted" entries.
>
> Thanks to Eric Dumazet for reminding me of the memory barriers.
Fix the comment below and you can add:
Signed-off-by: Ian Kumlien <[EMAIL PROTECTED]>
It's currently been running
On tis, 2007-05-29 at 16:03 -0700, David Miller wrote:
> From: Ian Kumlien <[EMAIL PROTECTED]>
> Date: Wed, 30 May 2007 00:51:52 +0200
>
> > On tis, 2007-05-29 at 15:44 -0700, David Miller wrote:
> > > From: "Michal Piotrowski" <[EMAIL PROTECTED]&g
On tis, 2007-05-29 at 15:44 -0700, David Miller wrote:
> From: "Michal Piotrowski" <[EMAIL PROTECTED]>
> Date: Wed, 30 May 2007 00:41:46 +0200
>
> > On 30/05/07, David Miller <[EMAIL PROTECTED]> wrote:
> > > From: Ian Kumlien <[EMAIL PROTEC
On ons, 2007-05-30 at 00:38 +0200, Thomas Gleixner wrote:
> On Wed, 2007-05-30 at 00:24 +0200, Michal Piotrowski wrote:
> > Hi Ian,
> >
> > (Thomas "The Wizard of Time" added to CC :))
>
> Added more wizards :)
>
> > On 29/05/07, Ian Kumlien <[
On ons, 2007-05-30 at 00:24 +0200, Michal Piotrowski wrote:
> Hi Ian,
>
> (Thomas "The Wizard of Time" added to CC :))
>
> On 29/05/07, Ian Kumlien <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > As the daystar sets, i try to play some with my new wou
this
happens:
http://pomac.netswarm.net/pics/kernel_panic.jpg
If i don't run powertop, it is rock solid... Compiling for hours,
running memtest for hours etc etc...
--
Ian Kumlien -- http://pomac.netswarm.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
ren't there before...
(It does fix the timeout problem)
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
On lör, 2007-01-20 at 21:43 +, Alistair John Strachan wrote:
> On Saturday 20 January 2007 19:59, Robert Hancock wrote:
> > Ian Kumlien wrote:
> > > Hi,
> > >
> > > I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama
> > > e
Hi,
I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama
enabled, to 2.6.20-rc5, which gave me problems almost instantly.
I just thought that it might be interesting to know that it DID work
nicely.
CC since i'm not on the ml
--
Ian Kumlien -- http://pomac.netswar
tswarm.net/misc/kernel-panic.jpg
PS. I could recreate the oops severaltimes until i put eth1 down, but i
haven't been able to since then (switched to rc7 without the LLC
option).
DS.
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
On Mon, 2005-08-15 at 09:21 +0200, Arjan van de Ven wrote:
> On Sun, 2005-08-14 at 23:24 +0200, Ian Kumlien wrote:
> > Hi, all
> >
> > I might be missunderstanding things but...
> >
> > First of all, machines with long pipelines will suffer from
ere some way to do the same test for the same time and measure
the differences in allround data? to see if we really are punished as
bad on accessing the data post copy? (could it be size dependant?)
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
89 matches
Mail list logo
