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, email to debian-68k-requ...@lists.debian
On Wed, Aug 14, 2013 at 10:40 AM, Geert Uytterhoeven
wrote:
> On Tue, Aug 13, 2013 at 6:32 PM, Geert Uytterhoeven
> wrote:
>> On Fri, 9 Aug 2013, Zach Brown wrote:
>>> On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
>>> > Josef Bacik writes:
>>> >
>>> > > So stripe_len shouldn't
On Tue, Aug 13, 2013 at 6:32 PM, Geert Uytterhoeven
wrote:
> On Fri, 9 Aug 2013, Zach Brown wrote:
>> On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
>> > Josef Bacik writes:
>> >
>> > > So stripe_len shouldn't be 0, if it is you have bigger problems :).
>> >
>> > The bigger probl
On Fri, 9 Aug 2013, Zach Brown wrote:
> On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
> > Josef Bacik 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 fir
On Fri, Aug 9, 2013 at 2:30 PM, Andreas Schwab wrote:
> Andreas Schwab writes:
>> Josef Bacik 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 __btrfs_map_block() ]
>> The bigger problem is that stripe_nr is u64
On 09-08-13 22:54, Thorsten Glaser wrote:
> Wouter, you might also want to review the m68k -di configs.
I'll look at it.
> I *think* I’ve got most of the modularisation for filesystems
> down, but *all* IDE and almost all SCSI drivers are missing,
> so a d-i built at the moment could only work on
Dixi quod…
>I’ve applied this as “hotfix” to 3.10.5-1+m68k.1 (Debian)
>and am building that, for the archive, until such time as
>we have a proper fix and/or problem analysis.
It’s uploaded.
Right now I started building one with Andreas Schwab’s patch
(thanks, again, as usual) applied instead.
On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
> Josef Bacik 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
On Fri, Aug 09, 2013 at 02:30:38PM +0200, Andreas Schwab wrote:
> Andreas Schwab writes:
>
> > Josef Bacik 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
Andreas Schwab writes:
> Josef Bacik 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 whole
> file.
Of course, what I mean
Josef Bacik 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 whole
file.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Ke
Dixi quod…
>#if 1 /*def CONFIG_CPU_HAS_NO_MULDIV64*/
>#include
>#else
Okay.
I cross-built a changed btrfs.ko with this one-line change,
scp’d that to the buildd, remade the initramfs, rebooted it
and it works.
I’ve applied this as “hotfix” to 3.10.5-1+m68k.1 (Debian)
and am building that, for
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 19:47:30.309776
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 indee
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
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
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, 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 ha
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.
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)
>
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)
21 matches
Mail list logo
