From: "Justin P. Mattock" <justinmattock@gmail.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux-ext4@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: INFO: task umount:1524 blocked for more than 120 seconds
Date: Sun, 16 May 2010 11:28:38 -0700 [thread overview]
Message-ID: <4BF03956.6020105@gmail.com> (raw)
In-Reply-To: <4BE890E8.9010700@s5r6.in-berlin.de>
well, I'm confused on this one..
If I cp -R 2.6.34(kernel) using the macbook pro
I can umount cleanly. But if I do the same for
the iMac9,1 I get this issue.
At first thought this might be an ext4 sync(and possibly)
hardware issue but if it was, then the macbook would portrait
similar issues as well(but could be wrong).
I did add(hopefully)the firelite device to the
workaround list with as many options as possible,
but had no difference(added/removed options as well)
here is what the patch looks like:
From 445d63a80e336408151f4dff7c23fb59a070d246 Mon Sep 17 00:00:00 2001
From: Justin P. Mattock <justinmattock@gmail.com>
Date: Sun, 16 May 2010 11:23:00 -0700
Subject: [PATCH] fix an umount bug
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/ieee1394/sbp2.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c
index 4565cb5..ce826f3 100644
--- a/drivers/ieee1394/sbp2.c
+++ b/drivers/ieee1394/sbp2.c
@@ -393,6 +393,17 @@ static const struct {
.model = SBP2_ROM_VALUE_WILDCARD,
.workarounds = SBP2_WORKAROUND_128K_MAX_TRANS,
},
+ /* SmartDsk FireLite Model #FWFL60-N */
+ {
+ .firmware_revision = 0x000470,
+ .model = 0x000000,
+ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS |
+ SBP2_WORKAROUND_INQUIRY_36 |
+ SBP2_WORKAROUND_MODE_SENSE_8 |
+ SBP2_WORKAROUND_FIX_CAPACITY |
+ SBP2_WORKAROUND_DELAY_INQUIRY |
+ SBP2_WORKAROUND_POWER_CONDITION,
+ },
/*
* iPod 2nd generation: needs 128k max transfer size workaround
* iPod 3rd generation: needs fix capacity workaround
--
1.6.5.2.180.gc5b3e
I'm might be wrong with the .firmware_revision and model
which I got echo 1 > /sys/module/sbp2/parameters/workarounds
only thing I didn't test was adding this patch, then doing
the echo command(not sure if it matters or not though).
Justin P. Mattock
next prev parent reply other threads:[~2010-05-16 18:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 21:46 INFO: task umount:1524 blocked for more than 120 seconds Justin Mattock
2010-05-10 22:21 ` Justin P. Mattock
2010-05-10 23:04 ` Stefan Richter
2010-05-10 23:40 ` Justin P. Mattock
2010-05-16 18:28 ` Justin P. Mattock [this message]
2010-05-12 15:04 ` Jan Kara
2010-05-12 15:16 ` Stefan Richter
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=4BF03956.6020105@gmail.com \
--to=justinmattock@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefanr@s5r6.in-berlin.de \
/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;
as well as URLs for NNTP newsgroup(s).