public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: linux-kernel@vger.kernel.org, k-ueda@ct.jp.nec.com,
	j-nomura@ce.jp.nec.com, jens.axboe@oracle.com,
	zaitcev@redhat.com
Subject: Re: kernel BUG at drivers/block/ub.c:820!
Date: Thu, 03 Apr 2008 15:57:25 +0200	[thread overview]
Message-ID: <1207231045.9155.6.camel@localhost> (raw)
In-Reply-To: <47F4C044.1090609@panasas.com>

On Thu, 2008-04-03 at 14:32 +0300, Boaz Harrosh wrote:
> > With git bisect I could came up with:
> > 610d8b0c972e3b75493efef8e96175518fd736d3 good
> > 3bcddeac1c4c7e6fb90531b80f236b1a05dfe514 compile error
> > 5450d3e1d68f10be087f0855d8bad5458b50ecbe compile error
> > b8286239ddaf2632cec65c01e68a403ac4c3d079 compile error
> > 7d699bafe258ebd8f9b4ec182c554200b369a504 bad
> > 
> > If I replace the BUG() with a printk my kernel survives the usb plug but
> > udev doesn't find the stick.
> > 
> 
> It is not the right fix but what happens if you change above code to this:
> 
> static void ub_end_rq(struct request *rq, unsigned int scsi_status)
> {
>         int error;
> 
>         if (scsi_status == 0) {
>                 error = 0;
>         } else {
>                 error = -EIO;
>                 rq->errors = scsi_status;
>         }
>         if (__blk_end_request(rq, error, blk_rq_bytes(rq)))
>                 __blk_end_request(rq, error, ~0);  /* <-- added line BUG removed. */
>         }
> }

I've tried this patch:

--- snip
diff --git a/drivers/block/ub.c b/drivers/block/ub.c
index c452e2d..0031e72 100644
--- a/drivers/block/ub.c
+++ b/drivers/block/ub.c
@@ -808,7 +808,7 @@ static void ub_rw_cmd_done(struct ub_dev *sc, struct ub_scsi_cmd *cmd)
 
 static void ub_end_rq(struct request *rq, unsigned int scsi_status)
 {
-	int error;
+	int error, size;
 
 	if (scsi_status == 0) {
 		error = 0;
@@ -816,8 +816,12 @@ static void ub_end_rq(struct request *rq, unsigned int scsi_status)
 		error = -EIO;
 		rq->errors = scsi_status;
 	}
-	if (__blk_end_request(rq, error, blk_rq_bytes(rq)))
-		BUG();
+	size = blk_rq_bytes(rq);
+	if (__blk_end_request(rq, error, size)) {
+		  printk(KERN_WARNING "ub_end_rq: __blk_end_request failed "
+			 "with size %i\n", size);
+		__blk_end_request(rq, error, ~0);
+	}
 }
 
 static int ub_rw_cmd_retry(struct ub_dev *sc, struct ub_lun *lun,

--- snip

The output on the console:

# usb 5-4: new high speed USB device using ehci_hcd and address 3
# usb 5-4: configuration #1 chosen from 1 choice
#  uba: uba1
# usbcore: registered new interface driver ub
# Initializing USB Mass Storage driver...
# usbcore: registered new interface driver usb-storage
# USB Mass Storage support registered.
# ub_end_rq: __blk_end_request failed with size 218
# ub_end_rq: __blk_end_request failed with size 218
# ub_end_rq: __blk_end_request failed with size 218
# ub_end_rq: __blk_end_request failed with size 218

I can mount the stick and read files from it without any additional
warnings. Just the initial detection seems to create the odd sized
requests.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.



  reply	other threads:[~2008-04-03 13:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-03  8:42 kernel BUG at drivers/block/ub.c:820! Martin Schwidefsky
2008-04-03 11:32 ` Boaz Harrosh
2008-04-03 13:57   ` Martin Schwidefsky [this message]
2008-04-03 14:15     ` Boaz Harrosh
2008-04-03 15:02       ` Martin Schwidefsky
2008-04-03 16:08 ` Kiyoshi Ueda
2008-04-03 15:18   ` Martin Schwidefsky
2008-04-03 16:30     ` Pete Zaitcev
2008-04-03 17:36       ` Boaz Harrosh
2008-04-04  4:30         ` Andrew Morton
2008-04-04 15:29           ` Kiyoshi Ueda
2008-04-04 19:45             ` Pete Zaitcev

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=1207231045.9155.6.camel@localhost \
    --to=schwidefsky@de.ibm.com \
    --cc=bharrosh@panasas.com \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=jens.axboe@oracle.com \
    --cc=k-ueda@ct.jp.nec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zaitcev@redhat.com \
    /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