On Thu, Feb 07, 16:16, Coly Li wrote
> From: Coly Li
> Date: Thu, 7 Feb 2019 15:54:24 +0800
> Subject: [PATCH] bcache: use (REQ_META|REQ_PRIO) to indicate bio for metadata
>
> In 'commit 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for
> metadata")' REQ_META is replaced by REQ_PRIO to indi
On Thu, Feb 07, 10:27, Coly Li wrote
> If different file system handles metadata flags in unified ways, it is
> OK to me to change the code to: !(bio->bi_opf & (REQ_META |REQ_PRIO)).
Yes, that's the smallest fix that should also go into 4.19-stable.
In the long run, we should try to get rid of t
On Thu, Feb 07, 10:43, Dave Chinner wrote
> File data readahead: REQ_RAHEAD
> Metadata readahead: REQ_META | REQ_RAHEAD
>
> drivers/md/bcache/request.c::check_should_bypass():
>
> /*
> * Flag for bypass if the IO is for read-ahead or background,
> * unless the read-ahead
On Wed, Nov 30, 09:53, David Miller wrote
> > OK, thanks for the clarification. There is no hurry, I just wanted to
> > make sure the patch doesn't get lost.
>
> There is never any ambiguity or guessing for networking patches, you
> can always simply check right here to see if a networking patch i
On Wed, Nov 30, 14:53, Greg Kroah-Hartman wrote
> > It fixes a regression introduced in 4.4.34 which makes systems
> > unbootable for us. We are currently running that patch on top of
> > 4.4.35 and I can confirm that it fixes the issue.
>
> I wait for networking stable patches to come from the ne
On Wed, Nov 30, 10:27, Greg Kroah-Hartman wrote
> Responses should be made by Fri Dec 2 09:26:46 UTC 2016.
If you haven't done so already, could you please add c9b8af13
(flow_dissect: call init_default_flow_dissectors() earlier) for
4.4.37?
It fixes a regression introduced in 4.4.34 which makes
On Tue, Nov 22, 14:04, Linus Torvalds wrote
> what's the situation on this issue? The bisection looks a bit odd,
> but the commit in question does end up changing the key_control->thoff
> value for the failure case, so maybe that in turn ends up screwing up
> a later skb_pull.
>
> I'm not seeing
On Tue, Nov 22, 11:17, Eric Dumazet wrote
> -late_initcall_sync(init_default_flow_dissectors);
> +core_initcall(init_default_flow_dissectors);
Indeed, that fixed it. Feel free to add
Tested-by: Andre Noll
Thanks a lot
Andre
--
Max Planck Institute for Developmental Biology
Spemannstr
On Tue, Nov 22, 18:08, Duyck, Alexander H wrote
> Okay I think I have figured it out, but I am not sure what a good
> solution is.
>
> I think the problem is the fact that the keys may not be initialized
> until init_default_flow_dissectors is called and I am not sure that is
> happening before th
g something like the patch below for mainline
and -stable.
Thanks
Andre
[1] http://people.tuebingen.mpg.de/maan/.eth_type_trans_panic.png
---
commit 3494d99764da2b7bbac5d0eed364d03552fefd36
Author: Andre Noll
Date: Tue Nov 22 11:34:11 2016 +0100
net: __skb_flow_dissect() must set ->
On Tue, Nov 22, 09:56, Eric Dumazet wrote
> >> @@ -157,6 +157,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> >> memcpy(key_eth_addrs, ð->h_dest,
> >> sizeof(*key_eth_addrs));
> >> }
> >>
> >> + barrier();
> >> again:
> >> switch (proto) {
> >>
On Tue, Nov 22, 18:06, Greg KH wrote
> On Tue, Nov 22, 2016 at 05:59:12PM +0100, Andre Noll wrote:
> > On Mon, Nov 21, 10:28, Greg KH wrote
> > > I'm announcing the release of the 4.4.34 kernel.
> > >
> > > All users of the 4.4 kernel series must upgrad
On Tue, Nov 22, 09:14, Eric Dumazet wrote
> We definitely want to fix the real bug, not working around it.
>
> Seems an aliasing problem, key_control and key_basic might point to
> adjacent memory
> and a barrier() would solve the issue as well.
This was also my first idea. I added some printk st
On Tue, Nov 22, 09:46, Eric Dumazet wrote
> This is an aliasing problem.
> Tom code is hard to read and understand.
>
> Andre, could you try :
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 69e4463a4b1b..b045980faaea 100644
> --- a/net/core/flow_dissector.c
> +++ b
On Fri, Jul 06, 13:52, Peter Zijlstra wrote:
> This then yields:
>
> P(\Union_{i=1..n} u_i) ~= \Sum_{k=1..n} (-1)^(k-1) (n choose k) u^k
>
> Which unfortunately isn't a series I found a sane solution for, but
> numerically (see below) we can see it very quickly approaches 1 when n
> >> 1.
Isn'
On 22:13, Boaz Harrosh wrote:
> All the scsi calls do not need any locks. The scsi LLDS never
> see these threads since commands are queued through the block
> layer.
That's what everybody believes, but nobody seems to know for sure.
Therefore I did what Andi suggested: Make a zero-semantics chan
On 20:29, Andi Kleen wrote:
> > Sure, I can do that if James likes the idea. Since not all case
> > statements need the BKL, we could add it only to those for which it
> > isn't clear that it is unnecessary.
> >
> > And this would actually improve something.
>
> I still think it would be a good
On 19:59, Andi Kleen wrote:
> But perhaps for such a long ioctl handler it would be better to move
> the lock/unlock_kernel()s into the individual case ...: statements;
> then it could be eliminated step by step.
Sure, I can do that if James likes the idea. Since not all case
statements need the
the BKL in the scsi code.
Signed-off-by: Andre Noll <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index f1871ea..3063307 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -48,6 +48,7 @@ static int sg_version_num = 30534;/* 2 digits for each
com
On 14:17, Richard Knutsson wrote:
> Would had preferred:
>
> if (x) {
>result = -E;
>goto out;
> }
>
> then:
>
> result = -E;
> if (x)
>goto out;
>
AFAIK, the second form is preferred in Linux because it is better
readable and it generates slightly better code.
Thanks for
he new unlocked_ioctl entry point.
Signed-off-by: Andre Noll <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index f1871ea..3063307 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -48,6 +48,7 @@ static int sg_version_num = 30534;/* 2 digits for e
On 17:52, Tuomo Valkonen wrote:
> On 2008-01-08, Andre Noll <[EMAIL PROTECTED]> wrote:
> > Use tune2fs to deactivate checking.
>
> So, a workaround is the answer to a clear bug. Typical FOSS.
It's not a workaround. The ext3 maintainers argue that every file
system shou
On 16:07, Tuomo Valkonen wrote:
> I hate it: every time Linux crashes, e.g. due to power failure, it takes
> almost an hour to boot, because the kernel has decided to corrupt the
> superblock to indicate that it's been years since last file system
> check.
Use tune2fs to deactivate checking.
>
On 00:22, Andi Kleen wrote:
> > /usr/bin/ld: section .text [ff700500 -> ff7007e3] overlaps
> > section .gnu.version_d [ff7004d8 -> ff70050f]
>
> Does this patch fix it?
Nope, with 0x600 I still get the same error. But it helped to further
increase VDSO_TEXT_OFFSET
On 14:04, Linus Torvalds wrote:
> So give it all a good whacking, and report back about all the neat new
> features!
Does overlapping sections count as a new feature? ;)
gcc -m elf_x86_64 -nostdlib -fPIC -shared -Wl,-soname=linux-vdso.so.1
-Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4
On 17:00, Bodo Eggert wrote:
> I've put the complete system into initrams, and I just want the kernel to
> run /sbin/init.
Did you try to exec /sbin/init as the last thing in the init script
of your initramfs? That worked for me some time ago.
Andre
--
The only person who always got his work do
led during bootstrap
>
> If we move the local_irq_enable() to the end of the function then
> add_partial() in early_kmem_cache_node_alloc() will be called
> with interrupts disabled like during regular operations.
>
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
On 11:58, Chuck Ebbert wrote:
> > Screenshots of the resulting kernel panics are available at
> >
> > http://www.systemlinux.org/~maan/shots/huangho-crash-2.6.21.1.png
> > and
> > http://www.systemlinux.org/~maan/shots/huangho-crash-2.6.21.5.png
> >
>
> Looks the the known oops in show_m
Hi
Our nfs server recently paniced under heavy nfs load. The backtrace
indicates that this might be a problem with the tigon3 network driver
which drives the onboard chips of the machine.
The first crash under 2.6.21.1 happened after about 4 days of uptime,
2.6.21.5 already crashed after 15 Minu
On 12:05, Mingming Cao wrote:
> > > BTW: Are ext3 filesystem sizes greater than 8T now officially
> > > supported?
> >
> > I think so, but I don't know how much 16TB testing developers and
> > distros are doing - perhaps the linux-ext4 denizens can tell us?
> > -
>
> IBM has done some testing (db
On 10:36, Jens Axboe wrote:
> - Edit .config and set CONFIG_DEBUG_INFO=y (near the bottom)
> - make oldconfig
> - rm block/cfq-iosched.o
> - make block/cfq-iosched.o
> - gdb block/cfq-iosched.o
>
> (gdb) l *cfq_dispatch_insert+0x28
>
> and see what that says. Should not take you more than a minut
On 10:02, Jens Axboe wrote:
> Do you still have the vmlinux? It'd be interesting to see what
>
> $ gbd vmlinux
> (gdb) l *cfq_dispatch_insert+0x28
>
> says,
The vmlinux in the kernel dir is dated March 5 and my bug report
was Feb 28. So I'm afraid it's gone. I tried the gdb command anyway
but i
On 19:46, Jens Axboe wrote:
> On Wed, Feb 28 2007, Andre Noll wrote:
> > On 16:18, Andre Noll wrote:
> >
> > > With 2.6.21-rc2 I am unable to reproduce this BUG message. However,
> > > writing to both raid systems at the same time via lvm still locks u
On 20:39, Andrew Morton wrote:
> On Wed, 28 Feb 2007 16:37:22 +0100 Andre Noll <[EMAIL PROTECTED]> wrote:
>
> > On 16:18, Andre Noll wrote:
> >
> > > With 2.6.21-rc2 I am unable to reproduce this BUG message. However,
> > > writing to both raid syste
On 16:18, Andre Noll wrote:
> With 2.6.21-rc2 I am unable to reproduce this BUG message. However,
> writing to both raid systems at the same time via lvm still locks up
> the system within minutes.
Screenshot of the resulting kernel panic:
http://systemlinux.org/~maan/shots/ker
On 10:51, Andrew Vasquez wrote:
> On Tue, 27 Feb 2007, Andre Noll wrote:
> > [ 68.532665] BUG: at kernel/lockdep.c:1860 trace_hardirqs_on()
>
> Ok, since 2.6.20, there been a patch added to qla2xxx which drops the
> spin_unlock_irq() call while attempting to ramp-up the queue
On 11:11, Andre Noll wrote:
> On 10:26, Andrew Vasquez wrote:
> > You are loading some stale firmware that's left over on the card --
> > I'm not even sure what 4.00.70 is, as the latest release firmware is
> > 4.00.27.
>
> That's the firmware which c
On 10:26, Andrew Vasquez wrote:
> You are loading some stale firmware that's left over on the card --
> I'm not even sure what 4.00.70 is, as the latest release firmware is
> 4.00.27.
That's the firmware which came with the card. Anyway, I just upgraded
the firmware, but the bug remains. The backt
Hi
On linux-2.6.20.1, we're seeing hard lockups with 2 raid systems
connected to a qla2xxx card and used as a single volume via lvm.
The system seems to lock up only if data gets written to both raid
systems at the same time.
On a standard kernel nothing makes it to the log, the system just
freez
39 matches
Mail list logo
