mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Seth Forshee <seth.forshee@canonical.com>
To: Daniel Barkalow <barkalow@iabervon.org>,
	Christoph Hellwig <hch@tuxera.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Problems with hfsplus on ipods in 2.6.38+
Date: Fri, 15 Jul 2011 09:39:00 -0500	[thread overview]
Message-ID: <20110715143900.GB19063@thinkpad-t410> (raw)
In-Reply-To: <alpine.LNX.2.00.1107142116260.2056@iabervon.org>

On Thu, Jul 14, 2011 at 09:26:11PM -0400, Daniel Barkalow wrote:
> Okay, I've applied that patch set, and it worked for me without any issues 
> thus far. If you're interested in the debugging output from a device that 
> doesn't work with vanilla but doesn't oops or panic with that patch set, 
> it's attached. I'm using 32-bit x86, if that helps for tracking down 
> differences.

Hrm, looks like I used %lu for sector_t instead of %llu, and that's
messing up the output on 32-bit builds. What I am able to see looks
correct though. I put up a new version of the patches with the output
fixed along with a new build on the bug.

I've had some success producing problems using scsi_debug with a 64-bit
build, specifically with 1K or 2K sectors. Actually a lot of odd things
happen with those sector sizes, and they happen whether using my patch
or reverting the two patches that change hfsplus to using bio, so those
problems seem unrelated. What I see is that the free/used space numbers
reported by df don't make sense given the actual files I've copied to
the volume. If I "fill" the volume (in quotes because really I haven't
copied in enough data to fill the volume, but it says it's full anyway)
df reports complete garbage. Then if I proceed to remove all files from
the volume df still reports that 50% of the space is used. These
problems aren't present with 512 byte or 4K sectors.

What I also see are GPFs in memory allocation code, which is what I
believe others have seen with my patch, and so far I haven't seen those
with the reversions. So I'm suspecting memory corruption, but I don't
yet see where the corruption is coming form. I found one problem, but I
don't suspect it's responsible for the GPFs.

I'm still investigating, but I won't really be able to spend much more
time on it until Monday.

Seth

  reply	other threads:[~2011-07-15 14:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-14  2:10 Daniel Barkalow
2011-07-14 13:53 ` Seth Forshee
2011-07-14 14:45   ` Christoph Hellwig
2011-07-14 15:24     ` Seth Forshee
2011-07-14 17:43   ` Daniel Barkalow
2011-07-15  1:26     ` Daniel Barkalow
2011-07-15 14:39       ` Seth Forshee [this message]
2011-07-15 15:43         ` Daniel Barkalow
2011-07-15 16:21           ` Seth Forshee
2011-07-18 13:36         ` Seth Forshee
2011-07-18 15:01           ` Christoph Hellwig
2011-07-18 16:46           ` Daniel Barkalow
2011-07-19  4:16             ` Daniel Barkalow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110715143900.GB19063@thinkpad-t410 \
    --to=seth.forshee@canonical.com \
    --cc=barkalow@iabervon.org \
    --cc=hch@tuxera.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®