On Tue, Aug 13, 2013 at 6:32 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Fri, 9 Aug 2013, Zach Brown wrote:
On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
Josef Bacik jba...@fusionio.com writes:
So stripe_len shouldn't be 0, if it is you have bigger problems :).
On Wed, Aug 14, 2013 at 10:40 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Tue, Aug 13, 2013 at 6:32 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Fri, 9 Aug 2013, Zach Brown wrote:
On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
Josef Bacik
On Wed, 2013-08-14 at 10:56 +0200, Geert Uytterhoeven wrote:
These bring in the 64-bit divisor from somewhere else, so they're less
trivial to fix.
Using div64_u64 or div64_s64 could fix it.
Maybe that could be added to do_div too.
--
To unsubscribe from this list: send the line unsubscribe
On Fri, Aug 9, 2013 at 2:30 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Andreas Schwab sch...@linux-m68k.org writes:
Josef Bacik jba...@fusionio.com writes:
So stripe_len shouldn't be 0, if it is you have bigger problems :).
[ lost context: this is about the first do_div() in
On Fri, 9 Aug 2013, Zach Brown wrote:
On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
Josef Bacik jba...@fusionio.com writes:
So stripe_len shouldn't be 0, if it is you have bigger problems :).
The bigger problem is that stripe_nr is u64, this is completely bogus.
Andreas Schwab sch...@linux-m68k.org writes:
Josef Bacik jba...@fusionio.com writes:
So stripe_len shouldn't be 0, if it is you have bigger problems :).
The bigger problem is that stripe_nr is u64, this is completely bogus.
The first operand of do_div must be u32. This goes through the
On Fri, Aug 09, 2013 at 02:30:38PM +0200, Andreas Schwab wrote:
Andreas Schwab sch...@linux-m68k.org writes:
Josef Bacik jba...@fusionio.com writes:
So stripe_len shouldn't be 0, if it is you have bigger problems :).
The bigger problem is that stripe_nr is u64, this is completely
On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
Josef Bacik jba...@fusionio.com writes:
So stripe_len shouldn't be 0, if it is you have bigger problems :).
The bigger problem is that stripe_nr is u64, this is completely bogus.
The first operand of do_div must be u32. This
tl;dr: we got the faulty code pinned down, it's m68k specific,
except the m68k specific part didn’t change from 3.2…
Joe Perches dixit:
Something like this maybe. (uncompiled/untested)
I tried this:
--- div64.h.orig2013-08-08 19:34:32.663540965 +
+++ - 2013-08-08
On Tue, 30 Jul 2013, Thorsten Glaser wrote:
NEW problem: btrfs doesn’t work at all. I had to reboot my
buildd into 3.2 using echo s/u/s/o /proc/sysrq-trigger as
the attempt to mount it left the system hanging there.
[0.00] Linux version 3.10-1-m68k (debian-ker...@lists.debian.org)
Geert Uytterhoeven dixit:
0: 222e ff74 movel %fp@(-140),%d1
4: 2a2e ff5c movel %fp@(-164),%d5
8: 2c2e ff60 movel %fp@(-160),%d6
c: 4c45 1402 divul %d5,%d2,%d1
10: 2d40 ff64 movel %d0,%fp@(-156)
14: 2d41 ff68 movel %d1,%fp@(-152)
18:
On Tue, Jul 30, 2013 at 11:07:30AM +0200, Geert Uytterhoeven wrote:
On Tue, 30 Jul 2013, Thorsten Glaser wrote:
NEW problem: btrfs doesn’t work at all. I had to reboot my
buildd into 3.2 using echo s/u/s/o /proc/sysrq-trigger as
the attempt to mount it left the system hanging there.
[
On Tue, 2013-07-30 at 13:13 -0400, Josef Bacik wrote:
I've looked at all the places we do divides in this function and it
doesn't look like we're doing this anywhere but I could be blind,
do_div seems a likely suspect...
/*
* stripe_nr counts the total number of stripes we
Josef Bacik dixit:
Can you gdb btrfs.ko and do
list *(__btrfs_map_block+0x11c)
Not easily (the kernel image is from a .deb package),
and even in a compile tree gdb just says:
No symbol table is loaded. Use the file command.
With a bit of cheating and a cross-compiler, this is:
(gdb) list
On Tue, Jul 30, 2013 at 07:02:29PM +, Thorsten Glaser wrote:
Josef Bacik dixit:
Can you gdb btrfs.ko and do
list *(__btrfs_map_block+0x11c)
Not easily (the kernel image is from a .deb package),
and even in a compile tree gdb just says:
No symbol table is loaded. Use the file
On Tue, 2013-07-30 at 16:40 -0400, Josef Bacik wrote:
So stripe_len shouldn't be 0, if it is you have bigger problems :). Is this a
corrupt fs or something? If there was some sort of corruption that occured
then
I suppose stripe_len could be 0 and we'd need to catch that somewhere higher
Josef Bacik dixit:
So stripe_len shouldn't be 0, if it is you have bigger problems :).
☺
Is this a corrupt fs or something? If there was some sort of
I don’t think so, I can access and use that filesystem under 3.2
just fine (it’s what I created it under, too, so it’s possible
that it’s indeed
17 matches
Mail list logo
