LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Robert Hancock <hancockr@shaw.ca>
Cc: Alexander <aledin@mail.ru>,
	linux-kernel@vger.kernel.org, ide <linux-ide@vger.kernel.org>,
	Jeff Garzik <jeff@garzik.org>, Tejun Heo <htejun@gmail.com>
Subject: Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Date: Sat, 12 Jan 2008 14:35:17 -0600	[thread overview]
Message-ID: <1200170117.3656.66.camel@localhost.localdomain> (raw)
In-Reply-To: <47891426.1020604@shaw.ca>


On Sat, 2008-01-12 at 13:25 -0600, Robert Hancock wrote:
> Alexander wrote:
> > Robert Hancock wrote:
> >> There's this patch which was intended to fix it:
> >>
> >> http://lkml.org/lkml/2007/11/22/148
> > 
> > I applied this patch to 2.6.24-rc7. Now at boot time my DVD-RW is
> > normaly detected as:
> > 
> > sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
> > 
> > But I cannot mount it. All my attempts failed with
> > 
> > ISOFS: Unable to identify CD-ROM format.
> > 
> > With mem<=4098M or sata_nv.adma=0 it still mounts and works ok.
> 
> As I wrote, it would appear that somehow the blk_queue_bounce_limit 
> setting that the driver has made is not being respected and the block 
> layer is still trying to feed it addresses over 4GB. Any ideas anyone?

Actually, I'd be very sceptical that the blk_queue_bounce_limit isn't
working as advertised; there'd be a large number of failures if it were
not.

However, the "as advertised" part doesn't seem to be generally well
understood.  The point being that block commands are only bounced if
they come from the filesystem or the user, not if they're generated
directly inside the kernel.  Since the fault occurs before mount, it's
suggestive of the latter.

A long time ago, GFP_KERNEL allocations meant that the memory allocated
was physically under 4GB.  Then x86_64 (and before it ia64) wanted to
break this.  So they introduced a new flag:  GFP_DMA32 that behaved like
the old GFP_KERNEL and then changed GFP_KERNEL on their architectures to
return memory from anywhere.  I'd strongly suggest some piece of kernel
memory was allocated for a transfer buffer without GFP_DMA32 and then
passed in to the driver.  Unfortunately, that could be anywhere inside
cdrom or sr.  Knowing what the actual command is might help ... some of
the distinctive MMC media ones only have a single source.

James



  reply	other threads:[~2008-01-12 20:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.krOVfyFmB2aqGjJIoHCLmQxecWc@ifi.uio.no>
2008-01-11  5:46 ` Robert Hancock
2008-01-12  8:25   ` Alexander
2008-01-12 19:25     ` Robert Hancock
2008-01-12 20:35       ` James Bottomley [this message]
2008-01-12 23:04         ` Robert Hancock
2008-01-12 23:27           ` James Bottomley
2008-01-13  1:38             ` Robert Hancock
2008-01-13  3:12               ` James Bottomley
2008-01-13 13:33               ` Alan Cox
2008-01-13 15:38                 ` James Bottomley
2008-01-13 16:29                   ` Alan Cox
2008-01-13 16:51                     ` James Bottomley
2008-01-15  1:41                       ` Robert Hancock
2008-01-15  2:23                         ` James Bottomley
2008-02-01  0:09 ` Robert Hancock
2008-02-01  9:59   ` Alexander
2008-02-04  8:29   ` Alexander
2008-01-10 13:44 Alexander

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=1200170117.3656.66.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=aledin@mail.ru \
    --cc=hancockr@shaw.ca \
    --cc=htejun@gmail.com \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM' \
    /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

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).