Robert Hancock wrote:
Can you (or others experiencing this problem) test the latest patch
attached to the RH Bugzilla entry here:
https://bugzilla.redhat.com/show_bug.cgi?id=351451
and see if it resolves the problem? I have one report of success so far.
I've tested this patch and it seems
Robert Hancock wrote:
Can you (or others experiencing this problem) test the latest patch
attached to the RH Bugzilla entry here:
https://bugzilla.redhat.com/show_bug.cgi?id=351451
and see if it resolves the problem? I have one report of success so far.
I've tested this patch and it seems
Robert Hancock wrote:
Can you (or others experiencing this problem) test the latest patch
attached to the RH Bugzilla entry here:
https://bugzilla.redhat.com/show_bug.cgi?id=351451
and see if it resolves the problem? I have one report of success so far.
I'll test it at this weekend.
--
To
Robert Hancock wrote:
Can you (or others experiencing this problem) test the latest patch
attached to the RH Bugzilla entry here:
https://bugzilla.redhat.com/show_bug.cgi?id=351451
and see if it resolves the problem? I have one report of success so far.
I'll test it at this weekend.
--
To
Alexander wrote:
Hello!
The problem described at https://bugzilla.redhat.com/show_bug.cgi?id=351451 and
at http://ubuntuforums.org/showthread.php?t=655772 and supposedly fixed by the
patch http://kerneltrap.org/mailarchive/linux-kernel/2007/11/25/445094 is still
there. I have compiled
Alexander wrote:
Hello!
The problem described at https://bugzilla.redhat.com/show_bug.cgi?id=351451 and
at http://ubuntuforums.org/showthread.php?t=655772 and supposedly fixed by the
patch http://kerneltrap.org/mailarchive/linux-kernel/2007/11/25/445094 is still
there. I have compiled
On Mon, 2008-01-14 at 19:41 -0600, Robert Hancock wrote:
> James Bottomley wrote:
> > On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote:
> >>> Yes, I concur for the short term. The other two possible courses of
> >>> action either involve long discussions (the different device one) or
> >>>
James Bottomley wrote:
On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote:
Yes, I concur for the short term. The other two possible courses of
action either involve long discussions (the different device one) or
you'll never quite be sure you got all the paths (the GFP_DMA32 one).
At least with
James Bottomley wrote:
On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote:
Yes, I concur for the short term. The other two possible courses of
action either involve long discussions (the different device one) or
you'll never quite be sure you got all the paths (the GFP_DMA32 one).
At least with
On Mon, 2008-01-14 at 19:41 -0600, Robert Hancock wrote:
James Bottomley wrote:
On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote:
Yes, I concur for the short term. The other two possible courses of
action either involve long discussions (the different device one) or
you'll never quite
On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote:
> > Yes, I concur for the short term. The other two possible courses of
> > action either involve long discussions (the different device one) or
> > you'll never quite be sure you got all the paths (the GFP_DMA32 one).
> > At least with this
> Yes, I concur for the short term. The other two possible courses of
> action either involve long discussions (the different device one) or
> you'll never quite be sure you got all the paths (the GFP_DMA32 one).
> At least with this one, you know everything will work.
The different device one
On Sun, 2008-01-13 at 13:33 +, Alan Cox wrote:
> > Other than that, I guess the solutions would be to just set a 32-bit
> > mask on the device if either port has an ATAPI device connected (which
> > is fairly ugly, considering that you could do things like hotplug an
> > ATAPI device when
> Other than that, I guess the solutions would be to just set a 32-bit
> mask on the device if either port has an ATAPI device connected (which
> is fairly ugly, considering that you could do things like hotplug an
> ATAPI device when the other port was in use, for example), or do
> something
Other than that, I guess the solutions would be to just set a 32-bit
mask on the device if either port has an ATAPI device connected (which
is fairly ugly, considering that you could do things like hotplug an
ATAPI device when the other port was in use, for example), or do
something to
On Sun, 2008-01-13 at 13:33 +, Alan Cox wrote:
Other than that, I guess the solutions would be to just set a 32-bit
mask on the device if either port has an ATAPI device connected (which
is fairly ugly, considering that you could do things like hotplug an
ATAPI device when the
Yes, I concur for the short term. The other two possible courses of
action either involve long discussions (the different device one) or
you'll never quite be sure you got all the paths (the GFP_DMA32 one).
At least with this one, you know everything will work.
The different device one is
On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote:
Yes, I concur for the short term. The other two possible courses of
action either involve long discussions (the different device one) or
you'll never quite be sure you got all the paths (the GFP_DMA32 one).
At least with this one, you
On Sat, 2008-01-12 at 19:38 -0600, Robert Hancock wrote:
> James Bottomley wrote:
> > On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote:
> >> I don't think the problem is that there's some buffer which is getting
> >> allocated above 4GB and never bounced, since the problem goes away if
>
James Bottomley wrote:
On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote:
I don't think the problem is that there's some buffer which is getting
allocated above 4GB and never bounced, since the problem goes away if
ADMA is disabled entirely and the DMA mask remains 32-bit always. My
On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote:
> I don't think the problem is that there's some buffer which is getting
> allocated above 4GB and never bounced, since the problem goes away if
> ADMA is disabled entirely and the DMA mask remains 32-bit always. My
> guess is something
James Bottomley wrote:
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
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
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
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.
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
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
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:
James Bottomley wrote:
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?
On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote:
I don't think the problem is that there's some buffer which is getting
allocated above 4GB and never bounced, since the problem goes away if
ADMA is disabled entirely and the DMA mask remains 32-bit always. My
guess is something is
James Bottomley wrote:
On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote:
I don't think the problem is that there's some buffer which is getting
allocated above 4GB and never bounced, since the problem goes away if
ADMA is disabled entirely and the DMA mask remains 32-bit always. My
On Sat, 2008-01-12 at 19:38 -0600, Robert Hancock wrote:
James Bottomley wrote:
On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote:
I don't think the problem is that there's some buffer which is getting
allocated above 4GB and never bounced, since the problem goes away if
ADMA is
Alexander wrote:
Hello!
The problem described at https://bugzilla.redhat.com/show_bug.cgi?id=351451 and
at http://ubuntuforums.org/showthread.php?t=655772 and supposedly fixed by the
patch http://kerneltrap.org/mailarchive/linux-kernel/2007/11/25/445094 is still
there. I have compiled
Alexander wrote:
Hello!
The problem described at https://bugzilla.redhat.com/show_bug.cgi?id=351451 and
at http://ubuntuforums.org/showthread.php?t=655772 and supposedly fixed by the
patch http://kerneltrap.org/mailarchive/linux-kernel/2007/11/25/445094 is still
there. I have compiled
34 matches
Mail list logo
